KR20120131246A - Systems and methods for distributing and redeeming credits on a broadcast system - Google Patents

Abstract

A method and system are provided that enable a receiver device to receive an electronic coupon from a mobile TV broadcast service provider. The coupon template may be broadcast to the mobile device. The coupon template may be used to communicate with a coupon manager to receive a digitally signed coupon. The coupon manager may use the received data to generate a digitally signed coupon for delivery to the receiver device over a unicast network. The digitally signed coupon may also be broadcast to the receiver device. The receiver device may identify the electronic coupon received using the digital signature to identify whether these coupons were intended for the receiver device. The electronic coupon may be redeemed at a point of sale. Merchants can also use the digital signature to verify the coupon locally. A coupon digital signature may be generated using a chain from the X.509 certificate to the root X.509 coupon-signing authority to allow recipients to verify that the coupons originate from a trusted entity.

Description

SYSTEM AND METHOD FOR DISTRIBUTING AND REMOVING CREDITS IN BROADCAST SYSTEM

Related application

The present application discloses US Provisional Application No. 61 / 042,597, filed April 4, 2008 and entitled "Method and Apparatus for Enabling and Applying Coupon and Token Usage in Mobile Television"; US Provisional Application No. 61 / 061,556, filed June 13, 2008 and entitled "Coupons for Broadcast Content Redemption"; And filed on April 5, 2008 and filed on April 2, 2009, claiming benefit of priority to US Provisional Application No. 61 / 120,355, entitled "Enhanced Coupons for Broadcast Content Redemption." Claims priority to US Patent Application No. 12 / 417,493, entitled "Systems And Methods For Distributing And Redeeming Credits On A Broadcast System," and is a CIP (continuation-in-part) patent application of US Patent Application No. 12 / 417,493. The entire contents of all of these applications are incorporated herein by reference.

This application also separately claims the benefit of priority to US Provisional Application No. 61 / 120,355, filed December 5, 2008, entitled "Enhanced Coupons for Broadcast Content Redemption."

Wireless communications technologies have exploded over the years. This growth has been spurred by wireless services that provide freedom of movement for the mobile public and cut the wire to hardwired communication systems. In addition, the increasing quality and speed of voice and data communications over wireless media have been attractive to additional users. As a result of these service improvements, the popularity of wireless services is expected to continue to grow rapidly.

A recent addition to wireless communication technologies is the ability to broadcast television to mobile users. Mobile broadcast users can use their cell phone or other wireless devices to view mobile editions of news, entertainment, sports, business, and other programming. These broadcast systems have seen a significant increase worldwide in usage and availability. Currently, users of mobile television and broadcast systems pay to receive program content. These costs vary depending on the service provider and the level of service selected.

Various embodiments herein provide a method and system for delivering digitally signed coupons to a receiver device and redeeming such coupons in order to have the right to watch broadcast content or to purchase a product or service. In an embodiment, the encrypted coupon template may be delivered to the receiver device user via the broadcast network. The receiver device may decrypt the coupon template and request a digitally signed coupon from the coupon manager using the data obtained from the coupon template. The coupon manager may receive a request for a digitally signed coupon along with the device data. The coupon manager may use the device data to generate a digitally signed coupon and deliver it to the requesting receiver device via a unicast network or the Internet. The signature on the coupon may be calculated through the entire coupon record, including the coupon identifier, which prevents it from being disguised as a coupon forgery or other legitimate coupon holder.

In further embodiments, digitally signed coupons may be delivered to the receiver device via the broadcast network. The receiver device may decrypt the received coupon to determine whether the coupon is intended for the receiver device. If the data received with the digital signature matches the data owned by the receiver device, the receiver device may store the coupon in memory. If the data received with the digital signature does not match the data owned by the receiver device, the receiver device may ignore the coupon.

In additional embodiments, digitally signed coupons may be redeemed at a point of sale. When presenting a coupon at a POS, the coupon may be confirmed by the POS based on the coupon data and the digital signature. Alternatively, the coupon itself may indicate that the merchant POS system should request the coupon manager to confirm the coupon by sending the coupon and receiver device data to the coupon manager. The coupon manager may decrypt the coupon signature and determine whether the coupon and the received data match the data retrieved from the coupon signature. If the data matches, the coupon manager may send a confirmation message to the POS to authorize or authenticate the purchase transaction using the presented coupon. In addition, a cancellation message may be sent to the receiver device to delete or cancel the presented coupon at the receiver device. If the data does not match, the coupon manager may send a reject message to the POS to notify the merchant that the coupon is not authorized or authorized for the purchase transaction.

In further embodiments, the digitally signed coupon may include a weight. These weights may be used by the coupon manager to determine whether two or more coupons may be combined in one purchase transaction. The coupon manager may receive coupon data from the POS and calculate the sum of the weights. If the sum of the weights of several coupons is greater than a predetermined value, the combination of those coupons may be rejected.

The accompanying drawings, which are incorporated herein and constitute a part of this specification, illustrate exemplary embodiments of the invention and, together with the general description provided above and the detailed description provided below, serve to explain features of the invention.
1 is a process flow diagram of conventional methods used for provisioning mobile devices to receive mobile broadcasts.
2 is a process flow diagram of an overview process for providing coupons to receiver devices in accordance with various embodiments.
3 is a network component diagram illustrating different components of a mobile broadcast TV system.
4 is a process flow diagram of an embodiment method for delivering credits or coupons to a receiver device.
5 is a message flow diagram of an embodiment method for delivering credits or coupons to a receiver device.
6 is a message structure diagram of an embodiment of a subscription response message.
7A is a message structure diagram of one embodiment of a bonus credit element.
7B is a message structure diagram of another embodiment of a coupon element.
7C is a diagram illustrating pointer criteria between a coupon document and service guide fragments according to an embodiment.
8 is a message structure diagram of one embodiment of a bonus credit element.
9 is a list of potential error codes for use in an embodiment.
10A is a process flow diagram of an embodiment method for delivering credits or coupons to a receiver device.
10B is a process flow diagram of another embodiment method for delivering credits or coupons to a receiver device.
11A is a message flow diagram of the embodiment method illustrated in FIG. 10A for delivering credits or coupons to a receiver device.
11B is a message flow diagram of the embodiment method illustrated in FIG. 10B for delivering credits or coupons to a receiver device.
12 is a message structure of one embodiment of a token purchase response.
13 is a process flow diagram of another embodiment method for delivering credits or coupons to a receiver device.
14 is a message flow diagram of the embodiment illustrated in FIG. 13.
15 is a process flow diagram of an embodiment method for redeeming credits or coupons.
FIG. 16 is a message flow diagram of the embodiment illustrated in FIG. 15.
17 is a process flow diagram of another embodiment method for redeeming credits or coupons.
18 is a message flow diagram of the embodiment illustrated in FIG. 17.
19 is a process flow diagram of another embodiment method for redeeming credits or coupons.
20 is a message flow diagram of the embodiment illustrated in FIG. 20.
21 is a process flow diagram of an embodiment method for managing expired credits or coupons.
22 is a process flow diagram of an embodiment method for managing credits or coupons used.
23 is a process flow diagram of an embodiment method of broadcasting an encrypted coupon template and retrieving a digitally signed coupon.
24 is a process flow diagram of an embodiment method of broadcasting a digitally signed coupon.
25 is a process flow diagram of an embodiment method for redeeming a digitally signed coupon.
26 is a process flow diagram of an embodiment method for managing a digitally signed coupon used.
27 is a process flow diagram of an embodiment method that enables combining two coupons for one purchase transaction.
28 is a component block diagram of a receiver device suitable for use in one embodiment.
29 is a component block diagram of a server suitable for use in one embodiment.

Various embodiments will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numbers will be used throughout the drawings to refer to the same or similar parts. References made to particular examples and implementations are for illustrative purposes, and are not intended to limit the scope of the invention or the claims.

The word "exemplary" is used herein to mean "functioning as an example, illustration, or illustration." Any implementation described herein as "exemplary" need not be construed as preferred or advantageous over other implementations.

As used herein, the terms “receiver device” and “mobile device” refer to cellular telephones, personal data assistants, palm-top computers, wireless electronic mail receivers (eg, Blackberry® and Treo® devices), multimedia Internet-enabled cellular telephones (eg, Blackberry Storm®), global positioning system (GPS) receivers, wireless game controllers, and programmable processor and memory and mobile broadcast television services. It refers to any one or all of similar personal electronic devices including receiver circuitry for receiving and processing. As used herein, a mobile device is a receiver device; Not all receiver devices are “mobility” like some embodiments and may be implemented with non-mobile receiver devices.

The words "credit", "incentive", "promotion", "coupon", and "token" refer to anything of value, such as the ability to receive one or more mobile television broadcasts or to purchase products or services. It is used interchangeably herein to refer to a valuable unit that may be redeemed or otherwise consumed to receive anything of value. In the context of various embodiments, such credits or coupons are rewarded by vendors, businesses, or content providers to reward consumers for purchasing various products or services or for viewing a particular content, or It may be published or generated as part of programs to motivate consumers to take a particular course of action, to view a particular program, or to purchase a particular product or service.

The term "unicast network" is used herein to refer to communication networks that transmit data to one destination. Examples of unicast networks include Wi-Fi and cellular data communication networks. Examples of unicast transmissions include simple message service (SMS), multimedia message service (MMS), and e-mail messages that may be carried over a cellular telephone data communication network.

The word "broadcast" is used herein to mean the transmission of information (information packets) that allows data to be received by multiple receiving devices. Examples of broadcast messages are mobile television service broadcast signals.

The term "content providers" is used herein to refer to companies that provide video, websites, and other data that is broadcast through mobile television systems. The term "network providers" is used herein to refer to entities that broadcast mobile television signals. Typically, network providers receive broadcast content from content providers. The term “advertisers” is used herein to generically refer to merchants, manufacturers, service providers, and other entities that may pay for product placements within a broadcast content or may purchase an advertisement.

The following reference table 1 is used herein and includes an alphabetical list of abbreviations with their associated meanings.

Table 1-Table of Abbreviations Abbreviation meaning BCMCS Broadcast and Multicast Services BDS Broadcast Distribution System BSM Broadcast Service Management / Provider DRM Digital Rights Management GBA Generic Bootstrapping Architecture ID Identifier KMS Key Management System LTKM Long Term Key Message MMS Multimedia Message Service MIKEY Multimedia Internet Keying NTP Network Time Protocol OMA BCAST Open Mobile Alliance Broadcast Working Group POS Point of Sale PPP Pay-Per-Play PPT Pay-Per-Time PPV Pay-Per-View RO Rights Object (ie, object for DRM) SMK Subscriber Management Key SMS Short Message Service SPE Security Policy Extension STKM Short Term Key Message TEK Traffic Encryption Key

The growing popularity of mobile television (TV) is a new source of revenue for content providers, network providers, and merchants, manufacturers, service providers, and other advertisers that can reach consumers using new media. Sources were provided. New revenue models include subscription-based sales of mobile television access, PPV or PPT mobile television access, advertising, and cross marketing of goods and services to consumers, through royalty or incentive programs. For example, mobile TV network providers can generate revenue from their services by selling subscriptions to users using access to limited mobile TV broadcast networks to subscribers. Merchants or manufacturers may advertise on mobile TV broadcast systems to generate revenue from the sale of their products and services. As usage continues to increase, mobile broadcast service providers may be provided with coupons and tokens that can be delivered to mobile receiver devices and exchanged to purchase mobile TV content (ie, viewing privileges), service, or products. You may want to encourage and simplify access to consumers through the use of the same credits.

Mobile TV users differ from home television viewers in that they use viewing devices (ie receiver devices) that they carry to receive mobile TV broadcast services and communicate via unicast messages. In addition, mobile devices can be personalized to users because in most cases only one uses the mobile device. Typically, users carry their mobile devices with them at all times, including when shopping for products and services. Thus, access and mobility to mobile TV broadcast services means that mobile devices may be very valuable marketing tools for reaching specific customers and building customer loyalty. Thus, mobile devices provide unique opportunities for rewarding important customers.

Providers may employ different methods to measure the value of their customers. For example, users who are significantly involved in the use of mobile devices to view mobile broadcast TV content may be particularly valuable to content providers such as television producers, movie studios, and music presentation houses. Using techniques available on mobile devices, the actual content viewed by users may be explicitly measured through in-program voting, betting, or the purchase of utilities, or the viewer It may be implicitly measured through the measurements. In addition, the measurement software can run in conjunction with a tuner on the mobile device to monitor channel changes to provide accurate measurements of broadcast viewing. In addition, the unicast communication capabilities of mobile devices can be used to receive immediate feedback and direct measurements of content viewing. In addition to making it possible to determine who is viewing their content, mobile devices provide content providers with important demographic information, so that content providers characterize their viewers with respect to important demographics and related consumer information. Allow to be mad

In addition to making it possible to measure general viewer engagement and demographics, pay-per-view and pay-per-time access services can enable content providers to identify and track real viewers. Thus, targeted consumer loyalty programs can be enabled on mobile devices in ways that are not possible through conventional broadcast television.

Since content providers can identify individual viewers, content providers may wish to implement targeted marketing programs aimed at retaining their customers, increasing customer satisfaction, and promoting similar content. . One means for building customer loyalty and expanding viewers involves rewarding customers with free access to broadcast content. For example, a content provider may want to authorize the content provider's royal viewers to allow them to watch their first show movie or to allow access to free music downloads. Thus, a content provider may want to offer coupons to these viewers of certain mobile TV programs in order to encourage those viewers of certain mobile TV programs to watch a similar movie of a conventional cinema. Similarly, content providers may want to provide credits or coupons to royal viewers in order to enable them to view more of their programs on mobile TV. In addition, content providers may want to perform cross-promotions that encourage viewers to watch content on a home (possibly fixed) subscription-based television system, such as a DirecTV ^™ or Dish ^™ network. .

Content providers are not alone to benefit from customer loyalty coupons that may be delivered to mobile devices. Commercial businesses that sell directly to customers, such as retail stores and consumer service providers, can identify their customers at a point of sale (POS). Typically, merchants have provided customers with paper coupons and similar promotional items. The technical capabilities of mobile devices provide merchants with new means to reward customer loyalty. For example, merchants may wish to provide loyal customers with credits or coupons that they can use to view mobile TV programs. If credits or coupons enable customers to view programs that include advertisements from the merchant that accepts the credit or coupons, such merchants may benefit from a double advertising benefit.

In addition, mobile TV broadcast service providers may also want to reward their customers with credits or coupons that enable their customers to view additional content or to purchase products or services at a discounted price. It may be.

Other reasons why businesses, content providers, and mobile broadcast network providers award credits or coupons to customers include: recognizing previous services or inducing future interactions; Compensating for unicast network traffic generated by service interaction activity; Rewarding or providing future incentives for watching advertisements; And offering bonuses to premium customers. Credits or coupons may also be awarded as part of customer loyalty programs (eg, air mileage, hotel points, meal tickets, etc.). Also, where consumer demographics can be accurately determined, credits or coupons may be provided to accurately cross sell the products or services desired by such consumers.

Many different mobile broadcast television services and broadcast standards are available or contemplated in the future, all of which may implement various embodiments and benefit from various embodiments. Such services and standards include the Open Mobile Alliance Mobile Broadcast Services Enabler Suite (OMA BCAST), MediaFLO, Digital Video Broadcast IP Datacasting (DVB-IPDC), and China Multimedia Mobile Broadcasting (CMMB). Typically, mobile broadcast transmissions are encrypted so that access to programming can be sold on a subscription or pay-per-view basis. Various mechanisms may be used to link the decryption keys to subscription purchases. Typically, mobile broadcast services use unicast communication networks, such as a customer's cellular telephone data service, to communicate subscription messages to and from specific customer mobile devices, and to use mobile broadcast programming to implement mobile television programming. Broadcast to all mobile devices. In summary, the mobile broadcast service provider may send messages that include information that enables the mobile device to generate the decryption keys needed to receive a particular broadcast. Decryption keys may be configured to expire after a predetermined amount of time, not only to enable pay-per-view type services, but also to limit the economic impact of decryption keys belonging to the public domain. have. In addition, messages providing decryption keys may include service restriction parameters that may be used to limit received broadcast services to specific programs, channels, or other market segments.

As an example, the OMA BCAST standard uses long term key messages (LTKM) that are sent to mobile devices over a unicast network to provide restricted access keys. The restricted access key is used by the mobile device to decrypt the traffic encryption key (TEK) contained in encrypted form in short term key messages (STKMs) that are broadcast regularly over the broadcast network. In the case of decryption, the TEK allows the mobile device to decrypt the encrypted broadcast content stream for a short period of time (eg, 2 minutes). If the TEK has expired, access to encrypted broadcast content will terminate unless a new TEK is obtained. To allow customers to view the entire programs, STKM messages can be broadcast sequentially so that new TEKs can be obtained from these STKMs using the long term key obtained from the LTKM.

Various embodiments are described below using the OMA BCAST standard description and message names as an example. Other mobile broadcast standards use other similar messaging structures in the message names and details, which is not important for the various embodiments. For example, DVB-IPDC uses Key Management Messages (KMM) in a manner similar to LTKM in the OMA BCAST standard, and uses Key Stream Messages in a manner similar to STKM in the OMA BCAST standard. The TEKs are used in a similar way to the TEKs of the OMA BCAST standard. Similarly, MediaFLO and CMMB use Encryption Management Messages (EMM) in a manner similar to LTKM in the OMA BCAST standard, and Encryption Codeword Message (ECM) in a manner similar to STKM in the OMA BCAST standard. ), And use Codewords (CW) in a manner similar to the TEKs of the OMA BCAST standard. Accordingly, the following descriptions are provided by way of example and are not intended to limit the embodiments or the claims to the OMA BCAST standard. For ease of reference, longer term right management messages will be referred to herein as long term decryption key messages or LTKM, and shorter term decryption key transfer messages are referred to herein as short term decryption key messages or STKM. The decryption key used to decrypt the encrypted broadcast content will be referred to herein as the content decryption key or TEK.

Currently, mobile broadcast TV systems allow the consumption of services or content through the purchase of subscription tokens or credits. That is, users must first pay in order to become subscribers, or must pre-pay for tokens for which the program may be redeemed for content. For example, in a typical mobile broadcast TV system, customers can purchase one token for every dollar they pay. Thereafter, an electronic wallet is activated within the mobile device so that tokens are deducted when users watch mobile TV programs. If the users have spent all of their tokens, they must purchase new tokens before they can watch additional mobile TV programs.

1 is a process flow diagram illustrating a current framework in which mobile device users can subscribe to or purchase mobile TV broadcast services. In generating broadcast services or content, the mobile TV service providers generated a set of usage charging rules and agreed to the set of usage charging rules (step 100). Based on these charging rules, the service provider generates subscriber management keys (SMKs) and establishes service registrations (step 102). The service provider may receive requests for service subscriptions from users (step 104), or may receive a request to purchase prepay-per-view or pay-per-time tokens (step (108)). The mobile broadcast service provider sells the requested subscriptions or tokens to the requesting users (step 106, step 110), and then the mobile broadcast service provider passes to the user's mobile device via the unicast network. Send an LTKM message (step 112). The LTKM contains a long term key for decrypting messages sent over the broadcast network. Typically, long term keys are typically subscription or service dependent. For example, users may subscribe with a foundational level of membership that allows users to receive only basic cable broadcast channels, for example on their mobile devices. At this level of membership, users may not be possible to viewing premium channels such as HBO ^® or ShowTime ^®. Typically, channel access control is facilitated by the use of different long term keys between the basic and premium channels.

LTKM may also include service rules governing the use of the long term key described above. Such rules define usage criteria and constraints, and typically their examples depend on the terms and conditions of the contract between the user and the service provider. For example, the service rule may inform the device of one of the following modes of authorized content consumption; There are existing subscriptions to live services, PPV access to live events, PPV access to live events or recorded content, or unrestricted playback modes of recorded content. The LTKM is sent over the unicast network in a message where the long term key is directed to the mobile device of a particular user, for example stored in a secure function on the terminal's secure memory or smart card. The service provider then broadcasts the STKM (step 114). Successively over time, the service provider also provides an encrypted program content stream (step 115). STKMs allow encrypted program content to be viewed by a mobile device. Every mobile device in the service provider network receives a broadcast of the STKM stream and the associated encrypted content stream. However, not all users can decrypt all STKM needed to decrypt the content. The viewing privilege of one user is based on the service rules defined in the LTKM for each mobile device. Thus, if the service rules provided in LTKM allow viewing of program content, the mobile device decrypts one or more TEKs to decrypt the content and display the content on the mobile device display (step 116). In the case where tokens are purchased, if the LTKM rules allow viewing of the program content, the tokens are first decremented from the mobile device electronic wallet (e.g. smart card) before the TEK is decrypted, and then the content is decrypted. To be used. However, if the service rules in LTKM do not grant access to the program content, the terminal will not be allowed to decrypt the encrypted TEKs in the STKM stream to allow viewing of the programming associated with the STKM stream.

However, current systems have limited capabilities for issuing credits to users for promotions or for generating purchase incentives in the form of coupons or free tokens. Currently, the only way that a mobile broadcast TV system provides credits to users is that coupons are sent to mobile broadcast TV users when a service is purchased. These coupons are sent to the users as part of the purchase data sent to the users' mobile devices with the content. Because these coupons are distributed when users purchase services, the coupons are targeted to specific users or user groups. In addition, tokens are sold to users by service providers. However, these tokens are only approved upon purchase request, and current mobile broadcast TV systems lack a means to deviate from the intended purchase from the intended token. In other words, tokens must be requested, and current mobile broadcast TV systems lack the ability to issue free or discounted tokens. In addition, the mobile broadcast TV network is not structured to convey an amount of tokens different from the amount of tokens requested. Thus, the content provider or network service provider wants to provide more tokens to the royal consumer than purchased, and the system will not allow such to occur. These current limitations allow mobile broadcast service providers, network providers, etc. to, for example, allow their customers to use their services, populate their unicast networks, view their advertisements, Or creating incentives for shopping at their stores.

In order to overcome these limitations and enable new marketing uses of mobile TV broadcast services, various embodiments methods and systems provide consumer awareness reward programs by making free or discounted products or services available to consumers. And transfer credits to mobile devices, which can be used in new revenue models. Content providers, mobile broadcast service providers, and advertisers may issue targeted credits (eg, coupons and tokens) for mobile device users. These credits may then be used for complementary or discounted viewing of additional mobile TV content, or for the purchase of products or services, thus allowing users to continue or increase their use of the mobile broadcast TV system. It may also generate incentives to do so.

Within various embodiments, credits may be awarded to users for different reasons. For example, credits may be provided to users for free service trials, content sampling, loyalty awards, early bird awards, new subscriber service discounts, and royal subscriber content discounts. Credits may be issued in different types of restrictions that may be specified by the creator of the credit. Universal Credit may be used to purchase any products and services anywhere. For example, a universal credit may be used to make a purchase at a POS for online shopping or to purchase mobile broadcast TV services. Credits may also be limited to program credits, which may only be used to purchase programs from a mobile broadcast TV system. In addition, the credit may be a specific credit that may only be used for purchasing a particular service or product, such as products from the merchant or manufacturer that generated the credit.

In various embodiments, the credits may be provided in the form of tokens or coupons that may be used to purchase free or discounted services, programs, or products, such as the type of currency. For example, users may use tokens to purchase pay-per-view (PPV) mobile TV programming for viewing on their mobile devices. Tokens may be provided to users free or discounted as a credit or promotion to generate incentives for users to purchase products and services. As defined in OMA BCAST 1.0, there are two types of tokens for the measured consumption of broadcast services. "User" tokens may be used to consume any content item under the user's membership level as defined in the service guide rules. "Service" tokens are limited to programs available under a particular service of the user's member. There is no value at all in some mobile broadcast TV systems, such as BCAST, where there may be no distinction between subscription and subscription from a service guide and programming viewing perspective. However, the flexible exchange of tokens or coupons for obtaining goods, services and / or programming may be handled more accurately in terms of membership, which may be associated with individual privileges.

Various embodiments allow coupons delivered to mobile devices to function as a type of currency that can be exchanged for a financial discount or discount when purchasing products and services. Unlike paper coupons, which are often widely distributed through mail, magazines, newspapers, and the like, coupons enabled in various embodiments may be delivered to a mobile device via mobile TV broadcast services. Once delivered to the mobile device, the user can use such coupons to obtain discounts and promotional items similar to how paper coupons are redeemed.

Various embodiment methods and systems may allow various advertisers to configure credits for different purposes. Credits may have restrictions on their use. For example, credits are valid for a particular time window, apply to any amount of purchased item, and may be configured independent of the actual price of the item. Credits may be exclusive (eg coupons that cannot be combined), or non-exclusive (eg coupons that can be combined if coupon providers are different). Credits may also be applied to a number of different purchase items (ie, individual products or services). Credits may be applied to products and services characterized by one set of purchase data (eg, one-time program view, product, or single service), as well as in the case of a subscription or contiguous service purchase. It may be applied to purchases characterized by multiple sets of purchase data. To support purchases of multi-data packages, such as a subscription, credits may be configured to apply to a subset of purchase data. Credits may be configured for only one user or group of users, such as royal or new users, who do not have the right to deliver, or may be configured to be transferable from the owner to another recipient.

2 is a process flow diagram of the overall process for creating credits, delivering credits to a user, and consuming credits on a mobile device. When users employ their mobile devices to view mobile broadcast TV content (step 200), their use (eg, level and type of use) may be measured by the mobile TV service provider. . Such tracking may be valuable for content providers as well as service providers based on measurements of both volume and selectivity of broadcast content viewed on users' mobile devices. Mobile TV service providers directly generate revenue for mobile broadcast service providers by benefiting from frequent use / consumption paid by subscription fees or one token purchase. Similarly, content providers benefit from the increased demand for their content that results in higher advertising revenues and costs paid by mobile broadcast network providers. In addition, the more users use the unicast features of their mobile devices to participate in programs such as voting for their favorite singers in TV singer competition shows, the more likely they are to cellular network providers that provide unicast services. More revenue is received. The viewing habits of each user may then be analyzed by service providers, content providers, and advertisers to target highly valuable users to send promotions and incentive credits or coupons. Thus, any one or more mobile broadcast service providers, unicast network providers, content providers, and advertiser businesses may generate targeted credits or coupons for delivery to a particular user or group of users ( Step 202). Such credits may include coupons or free tokens used to purchase a service or products. If a valued user or user group is identified and matched with the appropriate credit type, the credits may be sent to the identified user's mobile device (step 204). As described in more detail below, such credits may be delivered by unicast or broadcast transmission methods. When such credits are received, the mobile device stores them in security hardware, which may correspond to a removable smart card used in a mobile broadcast TV system or may be a secure memory on a terminal. The user may then redeem credits by purchasing products or services using their mobile device (step 206). For example, a royal user may receive credits from a mobile broadcast service provider that will be used to purchase a free cleansing product from a merchant or manufacturer while watching a soap opera on her mobile device while viewing an advertisement for the product. Once the credit is received, the user may purchase the product online by, for example, clicking the hyperlink URL provided with the credit to access the merchant's or manufacturer's web-store. Alternatively, the user may use the coupon like other downloadable e-coupons when visiting the store by presenting the mobile device at the point of sale and delivering the credit, or electronically recording the use of the credit.

3 is a diagram of a network component of a mobile broadcast TV system illustrating participants involved in delivering credits to mobile devices. In a mobile broadcast TV system, credits may be generated by various businesses, including broadcast service provider 30, third party businesses 50, and content providers 60. Broadcast service provider 30 is a company that provides typically subscription-based business relationships with end users. A broadcast network operator, which may be a mobile broadcast service provider 30, operates a broadcast network 80 that transmits mobile broadcast TV content to mobile devices 40. The broadcast network 80 includes only the downlink, such as FLO ^® - may be based broadcast / multicast system - a cellular as defined by or may be a dedicated broadcast transmission system, or the 3GPP MBMS, or 3GPP2 BCMCS. Exemplary service provider 30 companies include Verizon ^® , AT & T ^® , and T-Mobile ^® . These companies receive audio, video, and website content from content providers 60. These contents are then sent to a broadcast network operator, which broadcasts the content via their mobile broadcast TV network 80 or unicast network 70. In some cases, broadcast service providers 30 may also be cellular service providers, in which case they also provide unicast network 70 that provides voice and data services to mobile devices 40. And will operate. However, broadcast service provider 30 need not be a unicast (eg, cellular) network 70 provider. Even though the unicast network 70 and the broadcast network 80 are operated by different entities, the mobile broadcast service provider 30 still sends messages to the mobile devices (via the unicast network operated by another company). 40 and may receive from mobile devices 40.

Third parties 50 may include merchants and manufacturers such as HomeDepot ^®, Starbucks ^®, and Netflix ^®, which may wish to target a promotional for the mobile device user. The third parties 50 may interact with the users directly, such as when users visit their stores, or may indicate the broadcast service providers 30 by presenting advertisements in mobile broadcast TV programs. You can also interact with users.

Content providers 60 may include companies that provide content and programs for broadcast via mobile broadcast TV network 80. In addition, content providers may include advertising agencies, government agencies, and individuals that generate audio, video, and image content for broadcast. For example, the content provider may be a National Broadcasting Corporation (NBC) that provides news and entertainment content for broadcasting over the mobile broadcast TV network 80. Advertising agency content providers 60 may contract with third parties 50 to generate advertising content for their products and services. For example, Netflix ^® may contract with an advertising company to advertise Netflix ^® services.

In addition to unicast network 70 and mobile TV broadcast network 80, users may be able to access broadcast service provider 30 and content providers via other communication links, such as telephone (not shown) and Internet 90. 60). For example, users are maintained by mobile broadcast service provider 30 and content providers 60 via their mobile device 40 or a computer coupled to the Internet (via a separately shown cellular data network). You can also access web sites. Similarly, users may communicate with third parties 50 directly by accessing third party 50's websites via the Internet, or by going to the facilities of third parties 50.

Various embodiment methods and systems are credited via multiple delivery networks, such as SMS messages over broadcast network 80, Internet 90, unicast network 70, and directly at the point of purchase transaction. Allow their delivery and repayment. Mobile devices 40 of users may be targeted for distribution of credits based on their use of a mobile broadcast TV system. Credits may be delivered to the user's mobile device 40 directly or indirectly. The credits may be delivered directly to the mobile device 40, such as when a user makes a purchase on a business's website via the internet 90 using their mobile device 40, for example. Such credits may also be used as part of an established Internet session, such as in an online purchase, or through an out-of-band means, such as by SMS, MMS, or email message delivered via unicast network 70. 40). For example, the user's mobile device 40 may receive credits from Starbucks ^® for a free cup of coffee that can be sent via out of band methods, such as by SMS, MMS, or email. Regardless of how the credit is delivered, the user's mobile device 40 may be able to redeem credits via the broadcast service provider 30 to receive free or discounted mobile TV programming.

Credits may also be indirect to targeted users, such as when third party 50 submits credits to an intermediary, such as mobile broadcast service provider 30, for delivery to users' mobile devices 40. It can also be delivered. Delivery of credits to mobile devices 40 by broadcast service providers 30 may be accomplished using different methods. One method provides credits to users' mobile devices 40 when users communicate with service provider 30 to purchase viewing tokens or subscribe to a broadcast service. Delivery of such credits may be accomplished via a service subscription response message sent by the broadcast service provider 30 in response to the mobile device 40 subscription request message. For example, when mobile device 40 sends a subscription request message to service provider 30 to request an extension or upgrade for a service subscription (eg, basic to premium), service provider 30 responds to the subscription. As part of the message, third party 50 coupons may be delivered to the user's mobile device 40. Delivery of such credits may be through unicast network 70 and may be based on user values and habits. The second method may include transferring such credits to the users' mobile devices 40 when communication has not been initiated by the user's mobile device 40. In this method, service provider 30 may send (ie, push) credits to the user's mobile device 40 via a dedicated service provisioning message.

To support the delivery, processing, and redemption of mobile TV system credits and coupons, various contract and technical aspects may be adjusted before targeted delivery of credits to users is triggered. Contract aspects not only define message interface specifications between third parties 50 and mobile broadcast service provider 30, but also establish business rules related to consumption and charging semantics for credits and coupons. It may also include. For example, coupon type A may be defined to be redeemed for X minutes of viewing of a particular purchased mobile TV programming, which coupon A expires on date Y. Another example is free of chargeable by the user for a nominally-defined program viewing value of $ Z transferred from the bank of the third party 50 to the bank of the service provider 30 as part of the transaction. It may also include a token.

Technical aspects required to support mobile TV system credits and coupons may include using service provisioning messages to facilitate credit and redemption of credits. In addition to communicating information between the mobile broadcast service provider 30 and the mobile devices 40, service provisioning messages may allow the receiving mobile device 40 to prepare credits. Thus, mobile broadcast service providers 30 may generate specific and targeted service provisioning messages for credit delivery, and may target such messages, for example, to mobile devices of royal users. When the mobile devices are ready to receive credits, the mobile broadcast service provider 30 transfers the credits along with the credit's associated rules (ie LTKM) to the targeted mobile device 40, for example via the unicast network 70. You can also send.

4 illustrates one embodiment method for transferring credits from mobile broadcast service provider 30 to mobile devices 40 using a subscription response message. FIG. 5 is a message flow diagram illustrating exchange of messages that may occur between different mobile broadcast TV system components to convey credits in the embodiment method shown in FIG. 4. The embodiment method is described below with reference to both FIG. 4 and FIG. 5.

In the illustrated embodiment, mobile broadcast TV service provider 30 may soon send a report to third party 50 describing the programming content to be broadcast (the diagram corresponding to message 500 of FIG. 5). Step 302). This preceding notification of programming to be broadcast allows third parties 50 to not only evaluate the programming for placement of the advertisement, but also execute promotional campaigns such as providing credits or coupons to targeted consumers. . If the third party 50 receives the broadcast programming report (step 502), the third party 50 may use the credits in the form of the third party 50 in the form of coupons or tokens. May determine whether to provide to mobile devices 40 of. To extend the credits for the consumer, the third party 50 may send a credit request message to the service provider 30 (step 504 of FIG. 4 corresponding to message 502 of FIG. 5). This credit request message contains the value of the credits to be delivered, the applicability of the credits to be delivered (eg, programs, products, or services that can be redeemed), the effective dates of the credits to be delivered, and the redemption rules of the credits to be delivered. Details of the credits to be delivered may be identified, such as. Upon receiving such a credit request message (step 304), service provider 30 may send a credit response to third party 50 (step 306 of FIG. 4 corresponding to message 504 of FIG. 5). The third party 50 confirms that the service provider 30 has received and processed the third party 50 request, and carries data relating to previously agreed contractual provisions regarding consumption and payment. It may receive a credit response, which may be done (step 506), in preparation for delivering the third party 50 credits to the mobile devices 40, the service provider 30 may request that the third party 50 receive the credit response. May generate subscription response messages including the credit details provided by step 308. The structure, elements, and parameters of the subscription response message are described in greater detail below with reference to FIGS. . That The user mobile device 40 unicasts a request for a service to purchase viewing tokens, or to request or initiate a service coordination, such as pay-per-view tokens, a subscription request, or an upgraded service. May send over the network to the mobile broadcast service provider 30 (step 402 of FIG. 4 corresponding to message 506 of FIG. 5.) The mobile broadcast service provider 30 receives and processes a service request. (Step 310), and in response, may transmit a suitable service provisioning response message to mobile device 40 using unicast or broadcast network 70 (corresponding to message 600 of FIG. 6). Step 312 of Figure 4. This service response may include service coordination requested by the user as well as third party credits. The user's mobile device 40 may receive a subscription response message via unicast network 70, may access message content, and store credits in mobile device 40 memory, such as an electronic token purse. It may be (step 404). The mobile device user may then use these credits for purchasing services or products as specified in the credits. Methods by which users can redeem credits stored in mobile device 40 are described in more detail below with reference to FIGS. 15-20.

6 illustrates an example format and content of an embodiment subscription response message 600 suitable for delivering credits to mobile devices 40. This subscription response message 600 may be sent to the mobile devices 40 in response to a service request message sent by the mobile device 40 to purchase services from the service provider 30. The subscription response message 600 may include various components that may be classified into attributes and elements. As illustrated in FIG. 6, the subscription response message 600 may include optional attributes such as request ID 602, global status code 604, and adaptation mode 606. The request ID 602 may be an identifier for the corresponding service request message 506. To allow the correct responses to reach the correct requester, the request ID may identify the subscription response message 600 and correlate to the correct service request message 506. Using the request ID 602, the user's mobile device 40 can determine whether the correct service response has been received.

Global status code 604 may provide information regarding the overall result of the request according to certain defined return codes. Exemplary return codes are described in more detail below with reference to FIG. 9. By using the global status code 604, the mobile device 40 may determine whether the request was processed successfully. That is, the global status code 604 may communicate the status of the service request message 506 (ie, success or failure due to an error) sent by the user's mobile device 40. For example, if a global status code 604 is present in the subscription response message 600 and set to the value "0", this may mean that the request has been successfully processed and completed. Conversely, if the global status code 604 is present and the value is set to a non-zero value, this may mean that there was an error in the reception or processing of the request. Even if the service request message 506 was not successfully processed, the mobile broadcast service provider 30 sends credits even if the mobile broadcast service provider 30 cannot provide the specific service coordination requested by the mobile device. It is noteworthy that it may respond with a subscription response message 600. If the global status code 604 is not present in the subscription response message 600, this may mean that there was an error regarding one or more purchase item elements 608 associated with the request. Purchase item element 608 is described in greater detail below.

The optional adaptation mode element 606 may inform the mobile device 40 of the operation adaptation mode, which may be generic or BDS-specific. For example, if the value of this attribute is set to "fall", this may indicate that adaptation mode 606 is generic. If the value of this attribute is set to "true", this may indicate that the adaptation mode 606 is BDS-specific. According to various embodiments, the adaptation mode 606 may be present in the subscription response message 600 only if the global status code 604 indicates “success” and the underlying BDS is BCMCS.

The elements of the subscription response message 600 may further include the required purchase item element 608 and the operational elements of the DRM profile specifying portion 610 or the smart card profile specifying portion 612. The purchase item element 608 may describe what was purchased or received, such as the item requested in the service request message 506. That is, the purchase item element 608 may inform the mobile device 40 about whether the user's service request was successful and the requested item delivered. For example, if the service request message 506 requested digital rights (eg, a DRM profile) to play certain content, and the subscription purchase was successful, the purchase item element 608 is the right validity end time 622. It may also include. The rights validity end time 622 is described in more detail below with reference to the DRM profile portion 610. For DRM profiles or smart card profiles, if there is a failure in the purchase or subscription request, an itemized status code to indicate why the request was not accepted by the mobile broadcast service provider 30. 616 may exist as an attribute of the purchase item 608 element.

The purchase item element 608 may further include various attributes and elements. For example, purchase item element 608 may include the required global ID reference attribute 614 and the optional itemized status code attribute 616. In addition, the purchase item element 608 may include an optional bonus credit element 618 and a subscription window element 620. The global ID reference attribute 614 may be a designated ID for the purchase item element 608. Thus, the global ID reference 614 may use the global purchase item ID (not shown) found in the purchase item 608 to identify the purchased items. The global ID reference 614 may be, for example, any Uniform Resource Identifier (URI). A URI is, for example, a string of characters used to identify or name a resource on a unicast network. Such identification may enable to interact with representations of a resource over a network using specific protocols. The itemized status code may use the same returned codes, such as global status code 604, as described below with reference to FIG. 9, to specify the status for each purchased item (global status code). It may be a more specific status code 616 (as compared to 604).

Credits may be sent from the mobile broadcast service provider 30 to the mobile device 40 by using the optional bonus credit element 618. For example, credit (eg, coupon and / or token) data may be inserted into bonus credit element 618 before a service response is sent to mobile device 40. In this way, users may receive credits from the mobile broadcast service provider 30 when they send a request to purchase or subscribe to services. The credit type that may be part of the subscription response message 600 may vary and may include the type of requested service (eg, based on the use of the mobile broadcast TV system and the user's hobbies), the identity of the user requested service, or both. It may be bound to all. For example, zero or more standalone bonus credit sub-elements (also known as purchase data) may exist within purchase item element 608. These bonus credit sub-elements may include user specific credit data for bonus services that may result from the transaction. These credits may be stored in the memory of the mobile device and may be managed based on service guide rules and the member level of the user. Example embodiment bonus credit 618 message structures are described in more detail below with reference to FIGS. 7 and 8.

The required subscription window element 620 of the purchase item element 608 may include data related to the time interval for which the subscription or coupon is valid. Service provider 30 may use this element for time-based subscriptions and may include this element for PPV purchase response messages 600. The user mobile device 40 may use the information in the subscription window element 620 to determine the validity period of the subscription. The subscription window 620 element may further include the required start time attribute (not shown) and optional end time attribute (not shown). The start time attribute may include a network time protocol (NTP) time stamp that specifies the start of a subscription. The end time attribute may include an NTP time stamp that specifies the end of the subscription. In one exemplary embodiment, this attribute may be omitted for open-ended subscriptions.

The optional DRM profile specific portion element 610 may include a service and content protection DRM-profile specific portion. This part may be necessary to support the DRM profile and may not be applicable to the smart card profile. The DRM profile specific portion 610 may include an optional rights validity end time attribute 622 and an optional rights object acquisition protocol (ROAP) trigger element 624. The rights validity end time 622 attribute may be present to indicate the end time and date of the validity of the LTKM associated with the purchased content, which must be updated after that end time and date and the BSM accepts the request message. This field may be specified in the first 32 bit integer portion of the NTP time stamps. For example, this attribute may be validated when a rights object (RO) is broadcast. Otherwise, this attribute is not necessary. If there is an optional element ROAP trigger 624, it may be expected that the mobile device 40 uses it to initiate one or more LTKM acquisitions.

Optional smart card profile specific portion element 612 may include a service and content protection smart card profile specific portion. This part may be necessary to support the smart card profile and may not be applicable to the DRM profile. Smart card profile specific partial element 612 may include an optional LTKM element 626. LTKM element 626 may be a smart card profile mobile broadcast TV LTKM containing a base 64-encoded MIKEY message. This element may be present in the subscription response message 600 when the requesting mobile device 40 and the service provider 30 have agreed to “HTTP” (ie, the Internet) as the LTKM delivery mechanism during the registration procedure.

7A illustrates a diagram of a data architecture for one embodiment bonus credit element 618. As shown in FIG. 7A, the bonus credit 618 element includes a protection key 618a, description 618b, price information 618c, promotion information 618d, extension 618e, purchase item reference 618f. , Purchase channel reference 618g, terms of use 618h, personal extension 618i, ID 618j, version parameter 618k, valid-from parameter 618l, and valid- to) may include several parameters and sub-elements, including the parameter 618m. The protection key 618a may include an encrypted key that may be decoded based on the user's membership level as described in service guide rules. The description 618b may include a description of the product, a service being sold to a user, or a subscription in one or more languages. Price information 618c may include a description of the type of purchase or credit transaction.

Price information 618c may include two components, a discount amount 619a and a purchase type 619b. The discount amount 619a may include one or more monetary values, which may be represented as negative numbers, possibly in different currencies, representing savings that may be realized when using a discount / coupon. . A special value (such as 0) may be reserved to indicate that the associated discount / coupon makes the referenced purchase item free. In some embodiments, the discount amount 619a may be omitted if the value is taken as 0 to indicate that the item is free.

The purchase type table 619b shown in FIG. 7A shows different types of purchase or credit transactions that may be used to populate the price information sub-element 618c when a subscription response message is sent to the user's mobile device 40. Examples and values. Different types of purchase type values in the price table 619 include pay-per-time (one-time subscriptions, open-ended subscriptions, and time-based consumption of live content). PPT) Live, PPT playback to allow time-based consumption of non-live content, Pay-per-play (PPP) play to allow a certain number of playbacks on non-live content Back, unrestricted playback to allow unrestricted playback of non-live content, service token PPT live to allow time-based consumption of live content by using service tokens, non-live content by using service tokens Service token PPT playback to allow time-based consumption of users, user token PPT live to allow time-based consumption of live content by using user tokens, User token PPT playback to allow time-based consumption of non-live using user tokens, user token PPV live by using user tokens, user token PPP playback by using user tokens, service Extra service tokens purchased to add to the service perth linked to the service / content SEK / PEK ID key group that may require a valid LTKM to use tokens, and the mobile broadcast service provider (to add to the user perth) 30) Purchased extra user tokens that may be linked to the ID (which may not be linked to specific service content and may require a valid LTKM to be used), (eg, a product from a store, reserved for later use) Non-broadcasting products, such as manufactured products, and products reserved for exclusive use Bit (ie, the real world) may contain the product.

* Promotion information 618d may represent a discount / coupon that a user can obtain by purchasing a referenced purchase item. Extension 618e may identify additional programs, products, or promotions or include information about them. Purchase item reference 618f may be an identifier that identifies a particular purchased item associated with the promotional discount coupon. For example, purchase item reference 618f may identify a particular purchase item, such as CNN headline news. The purchase channel reference 618g may include information identifying where or how the user can purchase the referenced purchase item. In the case of coupons or tokens for programming purchases, the purchase channel reference 618g may identify the content provider (eg, Disney, AOL, CBS, etc.). In the case of coupons for purchasing products from merchants, the purchase channel reference 618g may be a store or chain (eg, Home Depot, Sears, etc.) where the product should be purchased.

The provision of use 618h may include information about how the credit may be used. For example, certain credits may not be duplicated or transferred to others. The terms of use 618h may define boundaries to allow the integrity of the credit to be maintained intact. This sub-element may also define the type of credit and what purpose this credit may be used for. For example, a coupon may only be used to receive discounts when purchasing content from mobile broadcast service provider 30. Such coupons cannot be used to purchase other products or services.

Private extension 618i may allow vendor- and application-specific extensions to be implemented in addition to the baseline SG standard. The credit ID 618j may include data that can be used to validate the credit and prevent the user from forging the credit, such as a nonce ID, an encrypted value, and the like. Coupon version 618k may include information for identifying a version of the coupon that may allow vendors to issue subsequent coupons over time for similar purchases with different terms and values. Thus, coupon version information may be used to support successive versions of the same type of coupon. The valid-from value 618l may include information about the date and time when the credit becomes valid. The valid-to value 618m may include information about the date and time when the credit becomes invalid and may no longer be used. The validity-end value may be omitted if the coupon does not expire.

In addition, bonus credit element 618 may include an extension URL element (not shown). Such a URL element will provide a pointer to a web resource that provides additional information related to the credit element. For example, the WWW page associated with the credit or coupon may arrive after the extension URL in the credit element. If the mobile device 40 has the ability to access the internet, the mobile device 40 uses HTTP to obtain additional information related to the credit or coupon by accessing the internet website.

Certain parameters and sub-elements may be necessary for the bonus credit element 618 to be valid and function. These essential parameters and sub-elements are illustrated in the message structure diagram shown in FIG. 8. These required fields include a purchase item reference field 618f, a purchase channel reference field 618g, a valid start field 618l, a credit ID field 618j, and a coupon version field 618k.

Coupon element 650 and alternative embodiments of the elements are shown in FIG. 7B. The sub-elements of this alternative coupon embodiment identify the coupon, describe the coupon, indicate the price or discount offered by the coupon, and identify the weight for the purpose of combining with other coupons (to be described in more detail below). And information required to identify the coupon, such as in the form of a digital signature. Exemplary information that may be included in a coupon object include: an identifier (ID), such as a globally unique identifier, a version number, a first moment of validity (effective start date); Last Moment Effective Date (Effective End Date) 652; A flag or value 664 indicating a coupon that must be confirmed by the issuer before being exchanged; Identifier 654 of the product or service to which the coupon applies; An identifier 656 for the channels through which the product or service must be purchased for the coupon to be valid; Description of the coupon 658; An identifier of the provider of the coupon (eg, the nature of the business issuing the coupon) 660; Multiple use weights 662, which will be described in more detail below with reference to FIG. 27; An indication of how soon the coupon can be reused after the coupon has been exchanged 666; Price information 668 including comparative price or discount value information; An indication 670 of the intended type of purchase item for which the coupon is valid; A monetary discount price 672 applied when the coupon is redeemed; An identifier of the currency in which the coupon is valid; An address 674, such as a URL, from which an image capable of coupon output may be obtained; A URI 676 indicating the authority to provide a digital signature to the coupon and exchange the coupon; An identifier 678 in the form of a user ID field and a user ID; And a digital signature 680, such as an XML digital signature from a publishing authority.

When an electronic coupon is delivered and processed as a separate coupon document or coupon object, the coupon object may be kept outside the service guide. Nevertheless, the coupon object may include a pointer to a fragment of a service guide that identifies information related to the coupon. 7C illustrates the relationship between coupon object 700 and service guide 710. In particular, coupon object 700 may include pointers 702, 704, 706 to provisioning fragments 712, 714, 716 in service guide 710 or to specific information fields within provisioning fragments. have. These pointers are in the form of globally unique pointers that do not change even when the service guide is updated so that the information referred to as coupon object 700 may always be available through pointers 702, 704, 706 included in the coupon. have.

In one embodiment, the credit ID field 618j may include additional sub-elements as shown in FIG. 8, such as the encryption parameter 618n, the credit identifier 618p, and the multipurpose signature 618o. Encryption parameter 618n may be used to specify an encryption algorithm and associated parameters such as encryption salt or nonce. The credit identifier 618p may be a globally unique identifier for the coupon.

The multipurpose signature 618o may be used to provide protection for the coupon if the multipurpose signature 618o is delivered over a hostile network. The multipurpose signature 618o may be a coupon using a cryptographic signature (i.e., an encrypted digest of all or part of the coupon field) and one or more X.509 digital certificates that are cached and / or retrieved on-demand by the merchant server. Can also be used to authenticate. In one embodiment, the multipurpose signature 618o may be used by the coupon issuer to generate a coupon that cannot be modified without detection (eg, by using known public key cryptography methods). In one embodiment, the multipurpose signature 618o may be generated using an X.509 signature layer so that the coupon recipient (eg, mobile device and merchant) can verify that the coupon was issued by a particular right and This is described in more detail below. In this embodiment, the signature algorithm may be specified in the X.509 certificate.

9 is a table 604a of different global status codes 604 and their associated status messages, which may be included in the subscription response message 600. For example, the subscription response message 600 that includes the global status code "000" may indicate that the request process was successful. The subscription response message 600 that includes the global status code "003" may indicate that the requested purchase item is unknown. The "003" code may also be received, for example, if the device has a cached service guide service with old information, in which case the user may reacquire the service guide. The subscription response message 600 including the global status code "009" may indicate that the charging step has failed. For example, if the agreed credit limit is reached, the account may be blocked, in which case the user may contact the service provider 30 to resolve the problem. In addition, the "009" code may be used between different businesses involved in a transaction. The subscription response message 600 including the global status code "011" may indicate that the operation that the device attempted to perform is not authorized under the contract between the service provider 30 and the user. Upon receiving such an error message, the user may contact the service operator 30 to change the contract terms. The "011" code may also be used between businesses. The subscription response message 600 including the global status code "015" may indicate that the requested service is not available due to transmission problems, in which case the request may be resumed at a later time. . Also, the "015" code may be used between businesses. The subscription response message 600 including the global status code "016" may indicate that the same request was previously processed, in which case the user or entity may check to see if the request has already been processed. . This may be done by determining if the LTKM has been received, otherwise re-enter the request. The user subscription response message 600 including the global status code "021" may indicate that the given information is invalid and cannot be used by the system. In such a situation, the user may recheck and resend the request. The subscription response message 600 that includes the global status code "022" may indicate that the request key materials and messages are invalid and cannot be completed. In such a scenario, the user may recheck and resend the request if necessary. The subscription response message 600 including the global status "031" may indicate that the user attempted to hire a bonus credit 618 with a coupon, but the coupon has an expiration date and is no longer valid for a purchase transaction. have. The subscription response message 600 containing the global status code "032" purchased the content object available by the user employing a validated bonus credit (which the coupon has), but the coupon was already used in a previous transaction and thus the coupon It may indicate that this is no longer valid.

In one embodiment, the credits may be delivered or pushed to the user's mobile devices 40 without receiving a voluntary service request from the user. That is, the mobile broadcast TV system may “bootstrap” the mobile devices 40 of the user, and the credits of the user's mobile device without the mobile devices 40 of the user sending the request message. Push to 40. Such delivery methods include third parties 50 and mobile broadcast service provider 30 delivering messages to all users using broadcast network 80, or using unicast network 70 to deliver messages. By delivering to specific users or groups of users, one may allow for sending credits to mobile devices 40. Bootstrapping the user's mobile devices 40 may be done by different methods. In one embodiment, request pool messages may be broadcast to the user's mobile devices 40, as described below with reference to FIGS. 10 and 11. Request pull messages may request credit purchase requests from the user's mobile devices 40. In another embodiment, as described below with reference to FIGS. 13 and 14, credit authorization push messages are generated by the user to allow the user's mobile devices 40 to receive credits without taking explicit action. May be broadcast to mobile devices 40.

To illustrate the transfer of credits using bootstrap methods, the following example embodiments describe free token delivery to users. Free tokens can be redeemed for mobile TV program viewing much like purchased tokens. Processes for transferring tokens are used as examples in the following embodiments, but the same processes may be used for transferring other types of credits, such as coupons, that can be redeemed for products or services. Thus, the following examples are not intended to limit the scope of the present invention to the transfer of tokens.

10A is a process flow diagram of an example embodiment method for bootstrapping users' mobile devices to receive free tokens using request pull messages. FIG. 11A is a message flow diagram of messages that may be exchanged between different mobile broadcast TV system components to convey tokens in accordance with the method shown in FIG. 10A. This embodiment is described below with reference to FIGS. 10A and 11A.

To initiate an involuntary token purchase request, the mobile broadcast service provider 30 may send a request pull message to the user's mobile device 40 (step 314 of FIG. 10A related to message 1100 of FIG. 11A). )). The request pool message 1100 may be sent over the broadcast network 80 or the unicast network 70. The request pull message 1100 is a message that initiates the credit transfer process described above with reference to FIGS. 4 and 5 by prompting the mobile device 40 to send a purchase request message. The user's mobile device 40 may receive and process the request pool message (step 406). Optionally, the user may be prompted to accept or reject the request pool (optional decision 408). This optional user selection may be useful for mobile device users, for example, where privacy or security concerns are more important than the desire to receive credits. If the user responds to the prompt by rejecting the request pool, mobile device 40 may simply ignore the request pool message. However, if the user responds to the prompt by accepting the request pool (ie, decision 408 = "yes"), the mobile device 40 may send a token purchase request to the mobile broadcast service provider 30. (Step 410 of FIG. 10A related to message 1102 of FIG. 11A). As described above with reference to FIGS. 4 and 5, the token purchase request message 1102 may be sent to the service provider 30 via a unicast network 70 or other network, such as the Internet 90. The token purchase request message 1102 may include information (eg, an identifier) specified in the request pool message, or the token purchase request message in the request pool message 1100 sent by the mobile broadcast service provider 30. A zero purchase request may be specified, such as for free tokens based on defined rules. Upon receiving the token purchase request message 1102 (step 316), the mobile broadcast service provider 30 may process the request to determine if any errors exist (decision 318). If the token purchase request message 1102 was not successfully received (ie, decision 318 = "no"), a token purchase response with an error message may be sent to the mobile device 40 (step 412 , Message 1104). This error message may include one or more codes and status messages described above with reference to FIG. 9. If the token purchase request was successfully processed (decision 318 = "yes"), the mobile broadcast service provider 30 may receive the user's mobile device 40 (step 414). A purchase response message may be sent (step 320 of FIG. 10A related to message 1104 of FIG. 11A). Token purchase response message 1104 may include attributes and elements described in greater detail below with reference to FIG. 12. Following transmission of the token purchase response message, mobile broadcast service provider 30 may send an LTKM message to mobile device 40 that includes the terms and conditions under which free tokens may be used with the tokens (FIG. Step 416 of FIG. 10A related to message 1106 of 11A. This LTKM may be transmitted over a unicast network 70 or other network, such as the Internet 90. Upon receiving the LTKM (step 416), the mobile device 40 may store the tokens in its memory (step 418 of FIG. 10A related to the internal message 1108 of FIG. 11A). Optionally, mobile device 40 may send a confirmation message to mobile broadcast service provider 30 to indicate secure receipt of tokens (step 420 of FIG. 10A related to message 1110 of FIG. 11A). . This acknowledgment message 1110 may be transmitted over a unicast network 70 or other network, such as the Internet 90. The confirmation message 1110 may be received by the mobile broadcast service provider 30 (step 324).

Although FIGS. 10A and 11A illustrate an example embodiment in which tokens are exchanged via token purchase request and purchase response messages, a general subscription request message as a mechanism for receiving credits, such as receiving coupons instead of tokens. The request pool process may be used to send (ie service requests). 10B is a process flow diagram of an example embodiment method for bootstrapping users' mobile devices to receive coupons via a service request using request pull messages. FIG. 11B is a message flow diagram of messages that may be exchanged between different mobile broadcast TV system components to deliver coupons in accordance with the method shown in FIG. 10B. Processes and messages with the same reference numerals are consistent with those described above with reference to FIGS. 10A and 11A.

10B and 11B, in response to receiving the request pool message 1100 (step 406 of FIG. 10B), the mobile device 40 sends a service request message to the mobile broadcast service provider 30. (Steps 411 and 317 of FIG. 10B corresponding to message 1103 of FIG. 11B.) Mobile broadcast service provider 30 may respond by sending a service response message to mobile device 30. FIG. (Steps 321 and 415 of FIG. 10B corresponding to message 1105 of FIG. 11B) Then, the mobile broadcast service provider 30 may have an LTKM message containing coupons (or other items of value). May be sent to mobile device 30 (steps 323 and 417 of FIG. 10B corresponding to message 1107 of FIG. 11B) Mobile device 30 may store the LTKM and coupons in memory. It may respond to a selective acknowledgment message as described above with respect to, steps (420 and 324) and a message 1110 (step 419 of FIG. 11b internal message 1109, and 10b of the).

12 illustrates various attributes and elements that may be included in an embodiment token purchase response message 1104. Token purchase response 1104 may include an optional request ID attribute 602 and a required global status code attribute 604. As described with reference to FIG. 6, request ID attribute 602 may be an identifier for a corresponding service request message. Thus, to allow correct responses to reach the correct requester, the request ID attribute 604 may identify the token purchase response message 1104 and correlate it to the correct token purchase request message 1102. Using the request ID attribute 602, the user's mobile device 40 can determine whether the correct token purchase response message 1104 has been received. As described above with respect to FIG. 6, global status code 604 may provide information regarding the overall result of a token purchase request in accordance with certain defined return codes. Example return codes are described in detail with reference to FIG. 9. By using the global status code 604, the mobile device 40 may determine whether the request was processed successfully or failed due to some error. That is, the global status code 604 may communicate the status of the service request (ie, failure due to success or error) to the user's mobile device 40.

In addition, the token purchase response 1104 may include optional elements such as the DRM profile specific partial element 610, the smart card profile specific partial element 612, and the bonus credit element 618. DRM profile specific partial element 610 and smart card profile specific partial element 612 are mutually exclusive. Thus, the token purchase response message may include only one of the DRM profile specific partial element 610 or smart card profile specific partial element 612. Service and Content Protection DRM profile specific partial element 610 may be necessary to support the DRM profile and may not be applicable to the smart card profile.

The DRM profile specific partial element 610 may include an optional element of the ROAP trigger 624. The ROAP trigger 624 element in the token purchase response message 1104 is similar to the ROAP trigger 624 in the subscription response message 600 with some differences. If the token purchase was successful, the token purchase response message 1104 may include a ROAP trigger 624 as an additional payload. Mobile device 40 may initiate one or more token acquisitions using this ROAP trigger 624 (ie, by initiating LTKM acquisition). This is the same function as the ROAP trigger 624 in the subscription response message 600 described above. However, unlike the ROAP trigger 624 element of the subscription response message 600, if the token purchase request fails because the mobile device 40 is not registered, for example, the token purchase response message 1104 is a ROAP as an additional payload. It may also include a registration trigger. Thereafter, the mobile device 40 may be prompted to initiate a registration process with the service provider 30, and then resend the token purchase request message 1102 if the mobile device 40 is successfully registered. .

The token buy response message may include the optional token authorization element 1202 and the LTKM element 626. Token authorization element 1202 may include various attributes, such as information about approved tokens in response to token purchase request message 1102. These attributes may include type 1204, amount 1206, and charging type 1208. The type attribute 1204 may specify the type of token authorized in the token purchase transaction. The different types of tokens that may be authorized and their assigned values are reserved tokens (value 0), tokens for the DRM profile (value 1), service tokens for the smart card profile added to the live PPT Perth. (Value 2), service tokens for the smart card profile added to the playback PPT personality (value 3), user tokens for the smart card profile added to the user personality associated with the service provider 30 ID (value 4). ), Tokens reserved for future use (values 5 through 127), and tokens reserved for future use (values 128 through 255). Both attribute 1206 may include information specifying the number of tokens authorized in the token purchase transaction. For type attribute 1204, the value specified in the attribute may correspond to the number of authorized tokens. The charging type attribute 1208 may include information regarding the type of charging to be associated with the token purchase transaction. Charging types include non-specific (value 0), prepaid (value 1), postpaid (value 2), preliminary for future use (values 3 to 127), and preliminary for exclusive use (values 128 to 255). You may. As described above with reference to FIG. 6, the LTKM 626 element may be a smart card profile mobile broadcast TV LTKM that includes a base 64-encoded MIKEY message. This element may be present in the token purchase response message 1104 when the requesting mobile device 40 and the service provider 30 have agreed on “HTTP” (ie, the Internet) as the LTKM delivery mechanism during the registration procedure.

Similar to the subscription response message 600 described above with reference to FIG. 6, the token purchase response message 1104 may include an optional bonus credit element 618 in which credits such as tokens or coupons may be sent to users. It may also include. For example, credit (ie coupon and / or token) data may be inserted into the bonus credit element 618 before the token purchase response 1104 is sent to the user's mobile device 40. In this way, users may receive credits from the mobile broadcast service provider 30 when their mobile devices 40 respond to a request pull message sent by the mobile broadcast service provider 30. have. The credit type that may be part of the token purchase response message 1104 may be changed, for example, the type of token being pushed to the user, the request pull message 1100 is sent or (the user's hobbies and mobile broadcast TV) May be tied to the identity of the user responsive to the purchase request message 1102 (based on the use of the system), or both. For example, zero or more standalone bonus credit parameters (also known as purchase data) may exist as an attribute of the purchase item 608. These bonus credit parameters may include user specific credit data for bonus services that may be generated by this token purchase transaction. The credits may be stored in the memory of the user's mobile device 40 and may be managed based on service guide rules and the member level of the user. Exemplary embodiment bonus credit 618 message structures are described in more detail with reference to FIGS. 7 and 8.

FIG. 13 illustrates a process flow of an example embodiment of bootstrapping users' mobile devices 40 to receive free tokens using token grant push messages. 14 is a message flow diagram illustrating messages that may be exchanged between different mobile broadcast TV system components for delivery of credits in accordance with the method illustrated in FIG. 13. This embodiment is described with reference to both FIG. 13 and FIG. 14.

To initiate the transfer of tokens to mobile device 40, mobile broadcast service provider 30 may send a token grant push message to mobile device 40 (step 321, message 1400). Mobile device 40 may receive and process a token grant push message (step 413). The token grant push message notifies the mobile device 40 that the LTKM will be sent so that the mobile device 40 can prepare to receive credits in the LTKM. Following the token grant push message 1400, the mobile broadcast service provider 30 may send an LTKM to the mobile device 40 identifying the free tokens and terms of use (step 322, message 1106). ). Upon receiving the LTKM 1106, the mobile device 40 processes the information (step 416) and stores the free tokens in a memory such as the mobile device security function 90 (eg, smart card memory). (Step 418, Internal Message 1108). Mobile device 40 may respond with a confirmation message to mobile broadcast service provider 30 (step 420, message 1110) to indicate that LTKM and free tokens have been successfully received and stored. Alternatively or alternatively, if tokens were not successfully stored in memory, mobile device 40 may include that information in the confirmation message (not shown). The mobile broadcast service provider 30 may receive the confirmation message 1110 (step 324) and may take appropriate steps based on the content of the message. For example, if the confirmation message 1110 indicates that the tokens were successfully received and stored by the mobile device 40, the service provider 30 may not take additional actions. However, if the confirmation message 1110 includes information indicating that the tokens were not successfully received or not stored in the mobile device 40 memory, the mobile broadcast service provider 30 may not be able to access the LTKM 1106. Appropriate action may be taken to resolve the situation, such as retransmitting the.

Once credits, such as free tokens or coupons, are passed to mobile device 40, the user may use them to purchase TV programs, services, or products. According to various embodiments, different methods for redeeming credits may be employed. One example repayment method includes broadcasting STKM credits may be used to purchase service content only from a particular mobile broadcast service provider 30. Another example uses unicast network 70 to allow mobile device 40 to reduce certain credits from an on-board electronics purse (implemented in a secure memory or smart card on a terminal) as part of a payment for a purchase. Send LTKM Perth mode. An LTKM Perth Mode message is a message that includes instructions that cause a mobile device to reduce credits from its electronic perth. Another example includes broadcasting an STKM null program message, which is a message instructing mobile device 40 to reduce certain credits from its electronic purse as part of a payment. Each of these credit repayment methods is described in more detail below with reference to FIGS. 15-20.

15 is a process flow diagram of an example embodiment for redeeming credits using STKM broadcasts. FIG. 16 is a message flow diagram of messages exchanged between different mobile broadcast TV system components to redeem credits in the method shown in FIG. 15. This embodiment is described below with reference to FIGS. 15 and 16.

According to various embodiments, credits delivered or pushed to mobile device 40 may include credits that may only be redeemed for purchasing free or discounted programs or content from mobile broadcast service provider 30. It may be. In such a scenario, the mobile broadcast service provider 30 may purchase a nominal or promotional program, which may be purchased using the STKM stream (message 1600, and also credits stored in the mobile devices 40). You may broadcast the content stream (messages 1601), step 326. The message 1600 includes broadcast delivery of the STKM stream.The message 1601 contains encrypted content as a continuous stream. Mobile device 40 processes the received STKM stream 1600 to determine whether credits in memory may be used to access a particular encrypted content stream (message 1601) associated with the STKM stream broadcast. It may be step 420. The broadcasted STKM stream 1600 is a broadcast network 80. May be delivered to all mobile devices 40 registered to the broadcast network, but included to access the associated encrypted content stream (messages 1601) associated with all mobile devices 40 that have received the STKM. It may not be possible to decrypt the encrypted TEK In order to access the encrypted content (messages 1601) associated with the STKM stream 1600, the receiving mobile device 40 must possess the correct codes and permissions. Such codes and permissions are defined by LTKM rules stored on mobile devices 40. For example, LTKM rules that may be used are passed along with credits as described above with reference to FIGS. May be ones, if the mobile device 40 receives the STKM stream 1600, the mobile device 40, It may own it in the mobile device security function 90 (step 422), and an internal message 1602) to determine whether LTKM rules allow access to the STKM stream 1600 (decision 422). If mobile device 40 determines that LTKM rules do not allow access to the STKM stream (decision 422 = "no"), mobile device 40 may ignore the STKM stream (not shown). If the LTKM rules allow access to the STKM stream (ie, decision 422 = "Yes"), the mobile device 40 decrypts one or more TEKs from the STKM stream for the availability of credits in Perth. The amount of credit required to do may be reduced from the credit perth (step 424, internal message 1604). Mobile device 40 may then decrypt at least a portion of the encrypted content stream (message 1601) using TEKs.

For example, message stream 1601 may carry encrypted content of a premium channel program, such as a new movie on HBO®. Only mobile devices 40 with previously received credits in the LTKM to access such programs may access and decrypt the HBO® program (messages 1601). LTKM and other mobile devices 40 that have not received the credits required for this promotion may not have access to the content associated with this STKM stream 1600.

Once the encrypted content 1601 is decrypted and accessed by the mobile device 30, the mobile broadcast service provider 30 may process credit redemption with the merchant 50 (steps 338, 516, Message (1606). Processing between service provider 30 and third party 50 or content provider 60 may be accomplished using any conventional business transaction process, including known e-commerce methods.

17 is a process flow diagram of an example embodiment that enables users to spend credit to purchase a service or product from a merchant. FIG. 18 is a message flow diagram of messages that may be exchanged between system components to implement the steps as shown in FIG. 17. This embodiment is described below with reference to both FIGS. 17 and 18.

In this example embodiment, a promotional credit delivered from LTKM to mobile device 40 may be used to purchase products while shopping at a merchant or vendor website. The process of receiving and storing credits is described above with reference to FIG. 10 or FIG. 13. Such credits may be used to pay for services or products while shopping, such as physically shopping or online shopping at a vendor's location (ie POS), or to receive discounts for services or products. have. The user may begin a shopping session with the affiliate 50 via his / her mobile device 40 (steps 428, 508, messages 1800). The user may indicate a desire to end a purchase and send information about coupons or credits stored in mobile device 40 from mobile device 40 to merchant 50 (message 1802). . This message may be sent over the Internet in an online shopping session, or may be sent to the mobile device's POS system via various known transmission methods, including, for example, manual entry of near field communication (NFC) links, displayed barcodes, or coupon IDs. May be transmitted from 40. Merchant 50 may determine whether the presented credits may be used as part of a payment for this transaction (decision step 510). If credits cannot be used for payment for this transaction, merchant 50 may allow the user to pay using other means of payment, such as using a credit card (steps not shown). However, if merchant 50 determines that the user's credits or coupons can be used (ie, decision 510 = "Yes"), merchant 50 sends a payment request to the mobile broadcast service provider 30. May be sent (step 512, message 1804). This payment request message 1804 may be transmitted via the Internet 90 or other network, and may identify the presented coupons, user, and / or mobile device 40. Upon receiving the payment request (step 330), the mobile broadcast service provider 30 may generate an LTKM Perth mode message and send it to the user's mobile device 40 (step 432, message 1806). )). The LTKM Perth Mode message 1806 may be sent to the user 40 using the unicast network 70, instructing the user's mobile device 40 to reduce appropriate credits from the mobile device 40 electronic perth. It may also include instructions. Mobile device 40 may receive LTKM Perth mode message 1806 (step 432), and may reduce credits from the electronic perth based on LTKM rules (step 434), internal message 1808. )). If the credits have not been fully or successfully reduced, the mobile device 40 may transmit a signal to the mobile broadcast service provider 30 (not shown). If the credits have not been completely or successfully reduced from the mobile device 40 Perth, the mobile broadcast service provider 30 may retransmit LTKM Perth mode (not shown). However, if the credits have been successfully reduced, the mobile device 40 may send a confirmation message to the mobile broadcast service provider 30 (step 426, message 1810). This confirmation message 1810 may be transmitted over the unicast network 70. The mobile broadcast service provider 30 may receive the confirmation message 1810 (step 334) and the merchant may send a payment response message (step 514) that the merchant may receive via the Internet or other network (step 514). 50) (step 336, message 1812). The payment response message 1812 may provide the merchant 50 with information that the credits were successfully reduced from the user's mobile device 40 Perth. Merchant 50 may complete a transaction with a user. The processing of credit repayment between the mobile broadcast service provider 30 and the merchant 50 may occur at the time of sale, or at a later time, for example with the transmission of the payment response message 1812 (steps 338, 516). )).

In one example embodiment illustrated in FIG. 19, an STKM null program message may be sent to the user's mobile device 40 to reduce credits to pay for purchases of products or service. Since the STKM null program message is broadcast to all terminals, only mobile devices involved in the shopping transaction should be affected by this special payment message. This is ensured by carrying a unique shopping transaction ID in the STKM null program message. All other mobile devices whose users are not involved in the shopping transaction may simply ignore this STKM message. 20 is a message flow diagram of messages that may be exchanged in the method illustrated in FIG. 19. This embodiment is described below with reference to both FIG. 19 and FIG. 20.

The process of receiving and storing credits is described above with reference to FIG. 10 or FIG. 13. As noted above, credits stored on mobile device 40 may be used to pay for a service or products when shopping at a vendor's location (POS) or while shopping online. The user may begin a shopping session with the merchant 50 via his / her mobile device 40 (steps 428, 508 of FIG. 19 corresponding to message 1800 of FIG. 20). The user may indicate a desire to end a purchase and send information regarding coupons or credits stored in the mobile device 40 from the mobile device 40 to the merchant 50 (the message of FIG. 20 ( 1802). This message may be sent over the Internet in an online shopping session, or may be sent to the mobile device's POS system via a variety of known transmission methods, including manual entry of near field communication (NFC) links, displayed barcodes, or coupon IDs, for example. May be transmitted from 40. Merchant 50 may determine whether credits may be used to pay for the transaction (decision 510). If credits cannot be used to pay for this transaction (step not shown), merchant 50 may allow the user to pay using other means of payment, such as using a credit card. However, if the merchant determines that the user may pay using the credits (ie, decision 510 = "yes"), the merchant 50 sends a payment request message to the mobile broadcast service provider 30. (Step 512 of FIG. 19 corresponding to message 1804 of FIG. 20). This payment request message 1804 may be transmitted by the Internet 90 or other network, and may identify the coupons, user, and / or mobile device 40 provided. Upon receiving a payment request (step 330), mobile broadcast service provider 30 may broadcast an STKM null program message to mobile device 40 (corresponding to message 2000 of FIG. 20). Step 331 of Figure 19). The STKM null program message 2000 may be encoded and transmitted over the broadcast network 80 so that only the user's mobile device 40 can receive and decrypt it. Mobile device 40 may receive an STKM null program broadcast message 2000 (step 438) and encrypt its content using the keys in LTKM associated with the credits stored on mobile device 40. Decrypt to determine if LTKM rules allow access to STKM null program broadcast message 2000 (decision 422). If the LTKM rule allows access to the STKM null program message 2000 (ie, decision 422 = "Yes"), the message may be sent to the Perth where the credits are stored (internal message 2002), and the credit May be reduced from Perth (step 434). If the credits are reduced, an acknowledgment message may be sent to the mobile broadcast service provider 30 (step 436 of FIG. 19 corresponding to message 1810 of FIG. 20). This confirmation message 1810 may be transmitted over the unicast network 70. The mobile broadcast service provider 30 may receive the confirmation message 1810 (step 334) and may send a payment response message to the merchant 50 (the diagram corresponding to the message 1812 of FIG. 20). 19, step 336). The payment request message 1812 may be sent over the Internet 90 or other network. Merchant 50 may receive a payment response that informs merchant 50 that the credits have been successfully reduced so that merchant 50 may end the sale (step 514). Credit repayment may then be processed between the mobile broadcast service provider 30 and the merchant 50 via any known financial transaction mechanism (steps of FIG. 19 corresponding to message 1606 of FIG. 20 ( 338, 516).

If the STKM null program message 2000 cannot or cannot be accessed by the mobile device 40, the mobile device 40 may ignore the message. Thus, credits will not be reduced and confirmation message 1810 will not be sent to service provider 30. Since the mobile broadcast service provider 30 does not receive the confirmation message, the mobile broadcast service provider 30 will send a payment response message 1812 informing the merchant 50 that no credits have been delivered. In such a scenario, merchant 50 may reject credits or coupons and may ask the user to use another form of payment for a service or product.

Certain rules may be defined to govern the use of credits. For example, credits may include expiration dates or may be used only once. For illustrative purposes, the following examples relate to the use of coupons, but the scope of the present invention is not limited to this form of credits. 21 is a process flow diagram of an example method for identifying and deleting expired coupons from an electronic purse of mobile device 40. The coupon may be received by mobile device 40 (step 2100) and may be stored in memory (step 2102). Thereafter, a request to use the coupon may be received by the mobile device (step 2104). As described above, the request may be received in the form of LTKM or STKM from broadcast service provider 30. If the coupon is accessed in response to the LTKM or STKM, mobile device 40 may determine whether the coupon has expired before allowing the use of the coupon (decision 2108). If the coupon has expired (ie, decision 2108 = "yes"), the coupon may be deleted from memory (step 2112), and a report of deletion of the expired coupon may be sent to the mobile broadcast service provider 30 May be sent (step 2114). This expired coupon deletion report may be sent via unicast network 70. If the coupon has not expired (ie, decision step 2108 = “no”), the coupon may be applied to the purchase based on the received LTKM or STKM as described above (step 2110).

22 is a process flow diagram of an exemplary embodiment method for identifying and deleting a used coupon. The coupon may be received by mobile device 40 (step 2100) and may be stored in memory (step 2102). A request to use the coupon may be received by the mobile device (step 2104). As described above, the request may be received in the form of LTKM or STKM from the broadcast service network 30. When the coupon is accessed in response to the received LTKM or STKM, mobile device 40 may determine whether the coupon has already been used or has been copied before the coupon is reduced to pay for the purchase transaction (decision ( 2200)). This determination allows the coupons to be defined, allowing the coupons to be used only once by some user, each time only by every user, or multiple times during the promotion period, or as expected by coupon creators. Make available according to other usage patterns that may be. If the coupon was used or was previously copied (ie, decision 2200 = "Yes"), the coupon may be deleted from memory (step 2112), and the report of deletion is sent via unicast network 70. May be sent to the mobile broadcast service provider 30, step 2114. If the coupon was not previously used or was not copied (ie, decision step 2108 = "no"), then The coupon may be applied to the purchase based on the received LTKM or STKM as shown (step 2110).

Although the foregoing embodiment is directed to mobile devices communicating with a mobile broadcast service provider via a unicast network, other communication links may be used. For example, such messages may be delivered to a server pool within a mobile broadcast service provider network via any network communication without departing from the invention and claims.

Embodiments described above deliver coupons or tokens to mobile devices via long term decryption key messages (eg, LTKM) and reduce coupons or tokens via short term decryption key messages (eg, STKM). Although controlling this, the claims may include implementations that use dedicated coupon transaction messages that are not the current part of known mobile broadcast standards. In cases where such standards are modified to include dedicated coupon transaction messages, such messages will be processed similar to the short and long term decryption key messages described herein and will include a number of elements thereof.

By using the public key cryptogram and electronic signature coupon, the user and / or retailer may each confirm that the coupon is unique without contacting the original issuer, or store a copy of all issued coupons. In an embodiment, the coupon is issued and may be available by only one or by a group of users and may not be reused by other users. In such a case, the digest of the multipurpose signature 618o may not only cover the entire contents of the coupon object, but also cover the account identification of the user (or user-group) authorized to use the coupon and other aspects of the coupon record. It may be. If a coupon is authenticated using digital signature technology, a third party attempting to submit a coupon that has never been issued will be easily detected since this signature will not be verified using an unauthorized account identification.

In an embodiment, the multipurpose signature 618o may be formed using an X.509 signature layer. X.509 includes, among other things, a public key infrastructure that specifies the format for the certificate path validation algorithm and public key certificate that allows the recipient to verify that the signature was generated by a certificate trusted by the root X.509 certificate. For the well-known ITU-T standard. In summary, digital signatures are obtained through a chain of certificates where each certificate specifies a higher order certificate, which chain is pending with a trusted X.509 certificate stored by the coupon redeemer. By leveraging the X.509 privilege, the root X.509 privilege can authenticate other companies that will issue valid coupons by handing over the child certificate. In this way, the coupon confirmation entity can hand off the coupon signature certification to the companies that wish to issue the coupon, which then wishes to issue an individual business that uses this certificate to issue a verifiable coupon. Child certificates may be issued to units or departments. The merchant point-of-sale system or merchant server 50 presented with the coupons verified by the digital signature using the X.509 signature layer is required to verify the coupon without having to establish a trust relationship with the individual coupon issuer. You can use cached verification certificates provided by X.509 privileges. As such, use of a digital signature formed using an X.509 signature layer allows the merchant system to validate the coupon if the merchant system trusts the X.509 authority, thereby providing for the delivery of the coupon delivered in accordance with various embodiments. It greatly simplifies repayment. This allows the merchant system to verify the coupon without communicating with the coupon issuer.

In an embodiment, coupons with a digital signature may be generated and broadcast to the mobile device 40 via the mobile multimedia broadcast network. 23 shows an embodiment method for broadcasting coupons with signatures. In an embodiment, merchant server 50 generates a coupon template that includes access information for obtaining the coupon, such as UR, L, and coupon ID number (step 2302), and sends the coupon template to a mobile broadcast network over a network such as the Internet. Send to cast provider 30 (step 2304). Mobile broadcast provider 30 may receive the coupon template from merchant server 50, encrypt it, and broadcast it (step 2306). Mobile device 40 may receive an encrypted coupon template from the broadcast transmission (step 2308). Mobile device 40 may decrypt the coupon template by using TEK (step 2310). As mentioned above, the TEK is retrieved based on the LTKM and STKM that the mobile device 40 received from the mobile broadcast provider 30. If the mobile device is one of the intended recipients of the broadcasted coupon, mobile device 40 may receive a TEK (via the LTKM and STKM methods) that allows the device to decrypt the coupon template. . If the mobile device is not part of the group for which the coupon is intended, the mobile device 40 may not have a corresponding TEK, and thus will not be able to decrypt the coupon template. Once the coupon template is decrypted, the mobile device 40 requests an electronic coupon available by using the Internet 90 over a unicast network and uses the coupon access information to host the website hosted by the merchant server 50. May be accessed (step 2312).

In this embodiment, the merchant server 50 may serve as a coupon data repository that may receive the mobile device 40 request for the electronic coupon (step 2314). Merchant server 50 may transmit a request for device identification information as well as any coupon data that was not delivered in the initial request, via an open Internet connection to mobile device 40 (step 2316). Mobile device 40 receives a request for identification and coupon data via the Internet 90 (step 2318) and, in response, sends the requested data to merchant server 50 (step 2320). Such mobile device identification information may be any form of information that will identify the device and / or user with respect to merchant server 50. Examples of such information include device identifiers (e.g., MAC IDs), device phone numbers, user account numbers, membership numbers, user names, passwords (e.g., personal identification) stored in device memory known to merchant server 50. Number (PIN)) and the like. During a transaction, one or more such device identifiers may be requested to be submitted by the mobile device.

The device identity data may be sent to the merchant server 50 using different methods. For example, device identity data may be automatically sent to the merchant server 50, such as in response to an information request. In such implementation, mobile device 40 may be configured to automatically respond to merchant server 50 request by providing request identification parameters in the response message to merchant server 50. Alternatively, the mobile device may notify the user of the request and send the device identity data to the merchant server 50 only when there is a user command. In this implementation, mobile device 40 notifies the user of a request from merchant server 50 for identification of data, prompts the user to approve or oppose the transmission of the requested data, and And may only be configured to respond when a user input is received that enables such identification data to be sent to merchant server 50.

Merchant server 50 may use the identification and coupon data to generate a coupon that includes the digital signature (step 2324). The digital signature digest may include a request for device identification information and a coupon ID. As mentioned above, the digital signature may be generated using a certificate having an X.509 signing layer associated with returning to root X.509 authority. As described below, the digital signature along with the device information and the coupon ID may be used at the POS to verify that the coupon is genuine before receiving the coupon. The confirmation method at the POS is described in more detail below with reference to FIG. Merchant server 50 may transmit the signed coupon to broadcast provider 30 (step 2326). The broadcast provider 30 may relay the signed coupon from the merchant server 50 to the mobile device 40 using the unicast network (step 2330). Alternatively, merchant server 50 may send the signed coupon directly to mobile device 40 via an open communication link through the Internet 90. Mobile device 40 may receive and store the signed coupon (step 2330) and notify the user about the receipt of an electronic coupon that can now be used in a transaction (step 2332).

In alternative embodiments, instead of providing a URL, the coupon template may include different communication indicators or addresses, such as telephone numbers. In this embodiment, mobile device 40 may communicate with merchant server 50 to exchange device identification and receive a signed coupon, for example, via a telecommunications network using SMS or MMS communication methods. have.

FIG. 24 illustrates another embodiment method in which merchant server 50 may generate a signed electronic coupon to broadcast to mobile device 40 without encrypting the broadcast coupon. In this embodiment, merchant server 50 generates a coupon having a digital signature comprising coupon data, coupon identification number, and intended recipient's mobile device identity data (if known) using conventional signature methods (step 2402, send the signed coupon to the mobile broadcast provider 30 to be broadcast (step 2404). As mentioned above, the digital signature may be generated using a certificate having an X.509 signature hierarchy associated with returning to root X.509 authority. As with the previous embodiments, the mobile device identity data may include any one or more device identifiers, such as a device MAC ID, phone number, PIN, account number, or group number. The group number may be assigned to the mobile device 40, and is assigned to or joined to a group of mobile devices or users (ie, group ID), for example, through contact or transaction with a merchant. For example, a merchant may have a loyalty program that a user can register with and may receive a group identifier that may be stored within a mobile device to receive a coupon. In this embodiment, the merchant publishes to broadcast an electronic coupon signed with a customer reward program identifier, so that only registered customers will receive redeemable coupons via the broadcast network.

Mobile broadcast provider 30 may receive the signed coupon from merchant server 50 and broadcast it as part of the regular broadcast transmission (step 2406). In this example embodiment, the digital signature confirms the use of the coupon by the user and the merchant server so that only certain mobile devices receive and process the coupon, so that the signed coupon is not broadcast to the broadcast provider (30). ) Does not need to be encrypted.

In order to receive and decrypt digitally signed coupons from merchant server 50, mobile device 40 may be pre-registered with merchant server 50. As part of pre-registration, the merchant may provide the decryption key to storage in the user's mobile device. This decryption key may be a standard public decryption key that may be shared by the merchant server 50 with the mobile device 40, such as an X.509 verifying certificate. In addition, during the pre-registration process, mobile device 40 may share device data with merchant server 50. Merchant server 50 stores and uses such device data received during pre-registration to generate coupons that include data having digital signatures including device data along with coupon data. This method allows the creation of an electronic coupon that can only be used by a particular mobile device because the digital signature can only be verified when it is with the device data. This allows granting a coupon to individual users or small groups of users to be broadcast in an unencrypted manner over broadcast network 80.

Upon receipt of the broadcast digitally signed coupon (step 2408), mobile device 40 may decrypt the coupon signature using the decryption key received during the pre-registration (step 2410). By decrypting the signature, mobile device 40 accesses encrypted signature data such as coupon data, device ID (step 2412), and determines whether the ID retrieved from the signature matches those stored on the device ( Decision step 2414). If the digital signature was generated using an X.509 signature certificate, the mobile device may also verify that the coupon was issued by an entity trusted by the root X.509 authority and thus by a trusted transaction. Mobile devices that do not have the appropriate decryption key may receive the coupon broadcast but will not be able to decrypt the signature and will ignore the data.

If the received device data in the signature matches the mobile device data (ie, decision step 2414 = “yes”), the mobile device 40 may store the coupon in the memory of the mobile device 40 (step 2416) and trade The user may be notified of the receipt of an electronic coupon that may now be used at the time (step 2418). If the device data obtained from the decrypted signature does not match the mobile device 40 data (ie, decision step 2414 = no), then the mobile device 40 determines that the coupon is intended for that mobile device 40. The coupon may be ignored as if it is not (step 2420). Also, if mobile device 40 does not cause the requested decryption key to decrypt the coupon signature, mobile device 40 may ignore the received coupon. Encrypting and authenticating an electronic coupon in a manner similar to providing a particular user or group of users over mobile broadcast networks without using the broadcaster's encryption method (e.g., the LTKM and STKM methods described above). Various combinations of digital signatures may be used.

The digitally signed coupon may be redeemed at the merchant's POS in a variety of ways. For example, depending on the type of coupon, the item may be purchased at a discount at a point of sale or may be free. 25 illustrates an embodiment method for redeeming signed coupons during a purchase transaction at a POS. During the purchase transaction (eg, during the “check out”), the user may provide the POS system 95 with a mobile device that stored the signed coupon. The mobile device 40 and the POS system may negotiate with the communication link, such as by using a well-known near field communication (NFC) link, through which the mobile device 40 is accompanied by the device identity data. Electronic coupon data may be transmitted (step 2502). The POS system 95 may receive the signed coupon and device identity data (step 2504) and send a request to verify the signed coupon to the merchant server 50 (step 2506).

The confirmation request message from the POS may include the coupon signature, coupon ID and receiving device identity data. Merchant server 50 may receive a confirmation request message (step 2508), decrypt the signature (step 2510), and compare the coupon ID and device identity data retrieved from the signature with the coupon ID and device identity data received from the POS. (Step 2512). If the digital signature was generated using an X.509 signature certificate, merchant server 50 may also confirm that the coupon was issued by an entity trusted by the root X.509 authority and thus is by a trusted transaction. . If the digital signature was correctly decrypted (confirms that the issuer is trusted) and the coupon ID and device identity data retrieved from the signature match that received from the POS system in the confirmation request message (ie, decision step 2510 = "Yes"), Merchant server 50 may verify the coupon (step 2514).

As part of the coupon confirmation, merchant server 50 also looks up the coupon ID in the coupon's database (e.g., the coupon object list (dead coupon object list) that is no longer available, as described below), so that the coupon You can also determine if the offer has already been redeemed and check the coupon field to determine if the coupon has expired, if the coupon is verified by digital signature and the data records indicate that the coupon has not been used and has not expired. The merchant server 50 may send a confirmation message to the POS system, step 2516. The POS system may receive the confirmation message, step 2518, and apply this coupon to the purchase transaction, step 2520. The POS system optionally sends a coupon use message to the merchant server 50 for the use of the coupon. The merchant server 50 may notify the merchant server 50, step 2522. The POS system may also send a coupon cancellation message to the mobile device 40, step 2526. The merchant server 50 receives the coupon use message; It may record that the coupon ID has been redeemed, step 2524. The mobile device 40 may receive the cancellation message and delete the coupon from the memory (step 2528).

If the coupon ID and device identity data retrieved from the signature do not match those received from the POS (decision step 2510 = "no"), or if the coupon has expired or has already been redeemed, merchant server 50 may reject the coupon; (Step 2530), a reject message may be sent to the POS system (step 2532). The POS system may receive a decline message and decline the coupon during the purchase transaction (step 2534).

FIG. 26 illustrates an example method of canceling a digitally signed coupon that has previously been redeemed or expired. Upon confirming or rejecting the signed coupon, merchant server 50 optionally sends a coupon cancellation message to mobile device 40 (step 2602) to indicate that the coupon should not be used for another purchase transaction. 40 may be notified. The coupon cancellation message may be sent to mobile device 40 using unicast, such as SMS, email, MMS or other conventional method. Mobile device 40 may receive a coupon cancellation message (step 2604). As part of receiving the coupon cancellation message, mobile device 40 may check the digital signature associated with the cancellation message to verify its authentication before deleting the associated coupon data from memory. This digital signature may be formed using an X.509 signature layer to enable mobile device 40 to confirm that the cancellation message was sent by an authorized right.

Upon receiving and confirming the coupon cancellation message, the mobile device 40 may delete the coupon stored in the mobile device 40 (step 2605) and delete the coupon in the mobile device memory in response to the merchant server 50 for approval or The cancellation may be approved (step 2606). Configuring the mobile device to delete or cancel the coupon and send a message to the merchant server 50 confirming the cancellation / deletion of the coupon protects the merchant and the coupon issuer from immoral users attempting to redeem the same coupon multiple times. .

To ensure reliable operation of the coupon distribution and redemption system, merchant server 50 may verify whether a coupon cancellation message approval has been received at decision step 2608. If a coupon cancellation approval message has been received (ie, decision step 2608 = “Yes”), the process of verifying and redeeming the coupon by merchant server 50 may end (step 2616). However, if a coupon cancellation approval message is not received (ie, decision step 2608 = "no"), merchant server 50 may access a database maintained by or accessible to the server to track the coupon as the coupon is used. A “dead coupon object” may be created (step 2610). The creation of a dead coupon object in the server accessible database causes the server to recognize that the coupon was redeemed previously if the coupon was presented to the merchant a second time. As such, as part of the coupon verification process described above with reference to step 2514 of FIG. 25, merchant server 50 may also check the dead coupon object database to determine whether the coupon was included in the list as it was redeemed. It may be. In an embodiment, the creation of the dead coupon object is a countdown timer that, when expired in step 2612, prompts the merchant server 50 to determine whether the coupon continues to be included in the list of dataaces, such as a dead coupon object database. You can also start If merchant server 50 is continuing to track redeemed coupons at that point (ie, decision step 2614 = “Yes”), the merchant server returns to step 2602 and sends another coupon cancellation message to mobile device 40. You may. If the merchant server 50 no longer estimates the redeemed coupon (ie, decision step 2614 = no), the coupon verification and redemption process by the merchant server 50 may end (step 2616). This process may also terminate if the coupon itself has expired since an expired coupon will be rejected based on its expiration parameters.

In an embodiment, the electronic coupon generated by the merchant server 50 may be used by the merchant server to define whether the coupon may be combined and, if so, to what extent it may be combined with other coupons. May include weights. The merchant may build rules for use by the POS system that will use the assigned coupon weights to determine whether a combination of multiple coupons is allowed. Merchant server 50 may implement rules such that the combination of coupons is not allowed if the sum of the weights assigned to the coupons presented to the POS system is greater than a predetermined maximum value. For example, the merchant may assign a weight of 0.2 to coupon A, a weight of 0.5 to coupon B, and a weight of 0.9 to coupon C. The merchant may also implement a rule that, when multiple coupons are presented to the POS system, may not allow combining of such coupons if the sum of the weights assigned to the coupons is greater than one. By these rules, the combination of coupon A and coupon B is allowed because the sum of the weights assigned to coupon A (0.2) and coupon B (0.5) is less than one. However, by the same rule, the combination of coupon A and coupon C is not allowed because the sum of the coupon weights assigned to coupon A and coupon B is 1.1, which is greater than one. For example, the combination of coupons A, B and C is also not allowed because the sum of the coupon weights is greater than one. This process can also validate or accept coupons without requiring the merchant server to contact the original coupon issuer (s).

27 illustrates an embodiment method of determining whether a combined use of multiple coupons with weights is allowed. A weight may be assigned to the coupon by the coupon issuer as part of the coupon generation process (step 2702). During a purchase transaction, a coupon manager, such as merchant server 50, may receive a coupon confirmation request from a POS system that includes coupon data for two or more coupons (see FIG. 25) (step 2704). The coupon manager may calculate the sum of the coupon weights (step 2708) and determine whether the sum of the coupon weights is greater than the predetermined weight (“n”) (decision step 2710). If the sum of the weights of the two or more coupons is less than or equal to "n" (ie, decision step 2710 = "yes"), merchant server 50 may demonstrate the combined use of two or more coupons for one purchase transaction ( Step 2714). If the sum of the weights of the two coupons is greater than "n" (ie, decision step 2710 = "no"), merchant server 50 may reject the combined use of two or more coupons for one purchase transaction (step 2712). Acceptance or rejection of the combined coupons may be communicated to the POS system in an acknowledgment or rejection message similar to that described above with reference to FIG. 25.

Conventional mobile devices 40 suitable for use with the various embodiments will have components in common in FIG. 28. For example, one example mobile device 40 may include a processor 191 coupled to an internal memory 192, a display 193, and a speaker 199. In addition, the mobile device 40 may have a cellular telephone transceiver 195 coupled to the processor 191 and / or an antenna 194 for transmitting and receiving electromagnetic radiation connected to the wireless data link. In some implementations, portions of processor 191 and memory 192 and transceiver 195 used for cellular telephony communications are collectively referred to as an air interface because they provide a data interface over a wireless data link. . Mobile devices typically also include a keypad 196 or a small keyboard, and menu selection buttons or rocker switches 197 to receive user inputs.

The processor 191 may be any programmable microprocessor, microcomputer, or multiple processor chip that may be configured to perform various functions, including the functions of the various embodiments described herein, by software instructions (applications). Or chips. In some mobile devices, multiple processors 191 may be provided, such as one processor dedicated to wireless communication functions and one processor dedicated to executing other applications. Typically, software applications may be stored in internal memory 192 before they are accessed and loaded into processor 191. In some mobile devices, processor 191 may include sufficient internal memory to store application software instructions. In addition, mobile device 40 may include a separate memory chip 190, such as a smart card for storing information related to credits, tokens, and coupons, such as an electronic personal purse, in accordance with various embodiments. In some mobile devices, the secure memory may be in a separate memory chip coupled to the processor 191. In many mobile devices 40, internal memory 192 may be nonvolatile memory or volatile memory, such as flash memory, or a mixture thereof. For purposes of this description, a general reference to memory is to the processor 191, including internal memory 192, memory chip 190, removable memory plugged into the mobile device, and memory within the processor 191 itself. It refers to all memory accessible by.

In addition, the plurality of embodiments described above may be implemented with any of a variety of remote server devices, such as the server 2800 illustrated in FIG. 29. Typically, such server 2800 includes a large capacity nonvolatile memory such as disk drive 2803 and a processor 2801 coupled to volatile memory 2802. The server 2800 may also include a compact disk (CD) drive 2806 and / or a floppy disk drive coupled to the processor 2801. In addition, the server 2800 may include network access ports 2804 coupled to the processor 2801 to establish data connections with network circuits 2805, such as the Internet.

The foregoing method descriptions and process flow diagrams are provided merely as illustrative examples and are not intended to require or represent that the steps of the various embodiments must be performed in the order presented. As will be apparent to one of ordinary skill in the art, the order of the steps in the foregoing embodiments may be performed in any order. Words such as "after", "after", "next", etc., are not intended to limit the order of the steps; These words are simply used to guide the reader through the description of the methods. In addition, any reference for claiming elements using, for example, indefinite articles ("a", "an", or "the") as a single type should not be construed as limiting the element to a single type.

The various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations thereof. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented in hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention.

The hardware used to implement the various illustrative logics, logic blocks, modules, and circuits described in connection with the aspects disclosed herein may be a general purpose processor, digital signal processor (DSP), application specific integrated circuit (ASIC) May be implemented or performed in a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but, in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine. A processor may also be implemented in a combination of computing devices such as, for example, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors in cooperation with a DSP core, or any other such configuration. Alternatively, some steps or methods may be performed by circuitry that is specific to a given function.

In one or more of the exemplary aspects, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over one or more instructions or code on a computer-readable medium. The steps of the method or algorithm disclosed herein may be practiced in an executed processor-executable software module, which may reside on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. The storage medium may be any available media that may be accessed by a computer. By way of example, such computer-readable media may comprise RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or instructions or data structures that may be accessed by a computer. It may include, but is not limited to, any other medium that may be used to carry or store the desired program code in the form. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a website, server, or other remote source, using coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technologies such as infrared, wireless, microwave, Cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, wireless, and microwave are included in the definition of the medium. As used herein, disks and disks include compact disks (CDs), laser disks, optical disks, digital versatile disks (DVDs), floppy disks, and Blu-ray disks. ) Typically reproduce data magnetically, but discs optically reproduce with lasers. Combinations of the above are also included within the scope of computer-readable media. In addition, the operations of the method or algorithm may reside as one or any combination or set of codes and / or instructions on a machine-readable medium and / or computer-readable medium, which may be integrated into a computer program product. have.

The preceding description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit and scope of the invention. Thus, the present invention is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein and the following claims.

Claims (16)

As a method of confirming the combination of multiple coupons,
For one purchase transaction, receiving a request for combining a plurality of coupons having a weight;
Calculating a sum of weights of the plurality of coupons;
Determining whether the sum of the weights of the plurality of coupons exceeds a predetermined value; And
Ascertaining the combined use of the plurality of coupons if the sum of the weights does not exceed the predetermined value. The method of claim 1,
Wherein the weight is assigned to the coupon by the coupon issuer. The method of claim 1,
Communicating a confirmation of the combined coupon to a point of sale system in a confirmation message. The method of claim 1,
Communicating the rejection of the combined coupon to a POS system in a reject message. A computer for confirming the combination of multiple electronic coupons presented for redemption,
For one purchase transaction, receiving a request for combining a plurality of coupons having a weight;
Calculating a sum of weights of the plurality of coupons;
Determining whether the sum of the weights of the plurality of coupons exceeds a predetermined value; And
Confirming the combined use of the plurality of coupons if the sum of the weights does not exceed the predetermined value
And a processor configured with processor executable instructions for performing operations comprising a plurality of electronic coupons. The method of claim 5, wherein
And the weight is assigned to the coupon by the coupon issuer. The method of claim 5, wherein
And communicating the approval of the combined coupon to a point of sale system in a confirmation message. The method of claim 5, wherein
And communicating the rejection of the combined coupon to a POS system in a reject message. A system for confirming the combination of multiple coupons presented for redemption,
Means for receiving a join request of a plurality of coupons having a weight, for one purchase transaction;
Means for calculating a sum of weights of the plurality of coupons;
Means for determining whether a sum of weights of the plurality of coupons exceeds a predetermined value; And
Means for confirming the combined use of the plurality of coupons if the sum of the weights does not exceed the predetermined value. The method of claim 9,
Wherein the weight is assigned to the coupon by the coupon issuer. The method of claim 9,
And means for communicating an approval of the combined coupon to a point of sale system in a confirmation message. The method of claim 9,
Means for communicating a rejection of the combined coupon to a POS system in a reject message. The computer,
For one purchase transaction, receiving a request for combining a plurality of coupons having a weight;
Calculating a sum of weights of the plurality of coupons;
Determining whether the sum of the weights of the plurality of coupons exceeds a predetermined value; And
Confirming the combined use of the plurality of coupons if the sum of the weights does not exceed the predetermined value
And store computer executable instructions configured to perform operations comprising a. The method of claim 13,
Wherein the weight is assigned to the coupon by the coupon issuer. The method of claim 13,
The operations further comprise communicating an approval of the combined coupon to a point of sale system in an acknowledgment message. The method of claim 13,
The operations further include communicating a rejection of the combined coupon to a point of sale system in a reject message.

Images