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

Abstract

A method and system is provided for enabling 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 the 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 the unicast network. The digitally signed coupon may also be broadcast to the receiver device. The receiver device may use the digital signature to identify the received electronic coupon to determine whether such coupons are intended for the receiver device. The electronic coupon may be redeemed at a point of sale (POS). The merchant may also use a digital signature to locally verify the coupon. The coupon digital signature may be generated using a chain from the X.509 certificate to the root X.509 coupon-signing privilege to ensure receivers are coupons originating from a trusted entity.

Description

[0001] SYSTEM AND METHODS FOR DISTRIBUTING AND REDEEMING CREDITS ON A BROADCAST SYSTEM FOR DISTRIBUTION AND RETURNING CREDITS IN A BROADCAST SYSTEM [0002]

Related application

This application claims priority from U.S. Provisional Application No. 61 / 042,597, filed April 4, 2008, entitled " Method and Apparatus for Enabling and Applying Coupons and Token Usage in Mobile Television "; U.S. Provisional Application No. 61 / 061,556, filed June 13, 2008, entitled " Coupons for Broadcast Content Redemption "; Filed on April 2, 2009, filed on December 5, 2008, and claiming the benefit of priority to U.S. Provisional Application Serial No. 61 / 120,355 entitled "Enhanced Coupons for Broadcast Content Redemption" US patent application Ser. No. 12 / 417,493 entitled " Systems And Methods For Distributing And Redeeming Credits On A Broadcast System ", filed a continuation-in-part (CIP) patent application of U.S. Patent Application No. 12 / 417,493 , The entire contents of both of which are incorporated herein by reference.

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

Wireless communications technologies have exploded over the years. This growth has spurred on by wireless services that offer mobile freedom to the mobile public and cut wire to hardwire communication systems. In addition, the increased quality and speed of voice and data communications over wireless media has attracted 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 view mobile editions of news, entertainment, sports, business, and other programming using their cell phones or other wireless devices. These broadcast systems have shown significant worldwide growth in use and availability. Presently, users of mobile television and broadcast systems pay for receiving program content. These costs vary depending on the level of service provider and selected service.

Various embodiments herein provide a method and system for delivering digitally signed coupons to a receiver device, having the right to view broadcast content, or redeeming such coupons for purchase of a product or service. In an embodiment, the encrypted coupon template may be communicated to the receiver device user via the broadcast network. The receiver device may decrypt the coupon template and request the digitally signed coupon from the coupon manager using the data obtained from the coupon template. The coupon manager may receive a request for the digitally signed coupon with the device data. The coupon manager may generate the digitally signed coupon using the device data and deliver it to the request receiver device via the unicast network or the Internet. The signature on the coupon may be calculated via an entire coupon record, including a coupon identifier that prevents the coupon from falsifying or pretending to be a legitimate coupon holder.

In a further embodiment, the digitally signed coupon may be communicated to the receiver device over 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 a further embodiment, the digitally signed coupon may be redeemed at a point of sale (POS). When presenting the coupon at the POS, the coupon may be verified by the POS based on the coupon data and the digital signature. Alternatively, the coupon itself may indicate that the merchant POS system must request the coupon manager to verify the coupon by sending 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 match, the coupon manager may send a confirmation message to the POS to authorize or authenticate the purchase transaction using the presented coupon. A cancel message may also be sent to the receiver device to delete or cancel the presented coupon at the receiver device. If the data do not match, the coupon manager may send a decline message to the POS to notify the merchant that the coupon is unauthorized or unauthorized for the purchase transaction.

In a further embodiment, the digitally signed coupon may include weights. Such a weight 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 the several coupons is greater than the predetermined value, the combination of the coupons may be rejected.

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate exemplary embodiments of the invention and, together with the general description given above and the detailed description given below, serve to explain the features of the invention.
1 is a process flow diagram of conventional methods used to provision mobile devices for receiving 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 the 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 the subscription response message.
7A is a message structure diagram of an embodiment of the bonus credit element.
7B is a message structure diagram of another embodiment of the coupon element.
7C is a diagram illustrating pointer references between a coupon document and service guide fragments in accordance with an embodiment.
8 is a message structure diagram of an embodiment of the bonus credit element.
Figure 9 is a list of potential error codes for use in the 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 method embodiment 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.
Figure 12 is a message structure of one embodiment of a token purchase response.
Figure 13 is a process flow diagram of another method embodiment for delivering credits or coupons to a receiver device.
14 is a message flow diagram of the embodiment illustrated in FIG.
15 is a process flow diagram of an embodiment method for redeeming credits or coupons.
16 is a message flow diagram of the embodiment illustrated in Fig.
17 is a process flow diagram of another method for redeeming credits or coupons.
18 is a message flow diagram of the embodiment illustrated in Fig.
19 is a process flow diagram of another method for redeeming credits or coupons.
20 is a message flow diagram of the embodiment illustrated in Fig.
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 used credits or coupons.
23 is a process flow diagram of an embodiment method for broadcasting an encrypted coupon template and retrieving digitally signed coupons.
24 is a process flow diagram of an embodiment method for 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 coupon that is digitally signed using.
Figure 27 is a process flow diagram of an embodiment method that allows combining two coupons for one purchase transaction.
28 is a component block diagram of a receiver device suitable for use in an embodiment.
29 is a block diagram of a component of a server suitable for use in an 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 like parts. References made to specific examples and implementations are for illustrative purposes only and are not intended to limit the scope of the invention or the scope of the claims.

The word "exemplary" is used herein to mean "serving as an example, instance, or illustration. &Quot; Any implementation described herein as "exemplary " is not necessarily to be construed as preferred or advantageous over other embodiments.

As used herein, the terms "receiver device" and "mobile device" are intended to encompass all types of communication devices, including cellular telephones, personal data assistants (PDAs), palm-top computers, Blackberry < (R) > and Treo (R) devices), multimedia Internet enabled cellular telephones (e.g., Blackberry Storm), Global Positioning System (GPS) receivers, wireless game controllers, and programmable processors and memory and mobile broadcast television services Refers to any one or all of similar personal electronic devices including receiver circuitry for receiving and processing signals. As used herein, a mobile device is a receiver device; Not all receiver devices are "mobile" as in some embodiments, and may be implemented with non-mobile receiver devices.

The terms "credit", "incentive", "promotion", "coupon", and "token" refer to anything that is valuable, such as the ability to receive one or more mobile television broadcasts or purchase products or services And is used interchangeably herein to refer to a valuable unit that may be redeemed or otherwise consumed to receive something of value. In the context of various embodiments, such credits or coupons may be used by vendors, businesses, or content providers to compensate consumers for purchasing various products or services or for viewing certain content, May be published or generated as part of programs to motivate consumers to take specific behavioral processes, view a particular program, or 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 WiFi and cellular data communication networks. Examples of unicast transmissions include simple message service (SMS), multimedia message service (MMS), and electronic mail messages that may be carried over a cellular telephone data communication network.

The term "broadcast" is used herein to refer to the transmission of data (information packets) which allows data to be received by a plurality of 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, web sites, and other data that is broadcast through a mobile television system. 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 generally refer to merchants, manufacturers, service providers, and other entities that may pay for product placement in broadcast content or purchase advertisements.

The following Reference Table 1 is used herein to include a list of abbreviations having their associated meanings in alphabetical order.

Table 1 - Abbreviations table 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 (Multimedia Message Service) MIKEY Multimedia Internet Keying (Multimedia Internet Keying) NTP Network Time Protocol OMA BCAST The Open Mobile Alliance Broadcast Working Group POS Point of Sale PPP Pay-Per-Play PPT Pay-Per-Time PPV Pay-Per-View RO A Rights Object (i.e., an object for DRM) SMK The subscriber management key (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) has led to new revenue streams for merchants, manufacturers, service providers, and other advertisers that can reach consumers using content providers, network providers, and new media. Sources. 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 loyalty or incentive programs. For example, mobile TV network providers can generate revenue from their services by selling subscriptions to users using access to restricted mobile TV broadcast networks to subscribers. Merchants or manufacturers may advertise on a mobile TV broadcast system to generate revenue from the sale of their products and services. As usage continues to increase, mobile broadcast service providers are able to offer coupons and tokens that can be delivered to mobile receiver devices and can be exchanged for purchasing mobile TV content (i.e., viewing privileges), services, or products You may want to encourage access to consumers through the use of the same credits and to simplify access.

Mobile TV users are different from home television viewers in that they use viewing devices (i.e., receiver devices) that they carry so that they can receive mobile TV broadcast services and communicate via unicast messages. In addition, mobile devices can be personalized for users because in most cases only one uses the mobile device. Typically, users carry their mobile devices 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 to reward critical 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 for content providers such as television producers, movie studios, and music presentation houses. Using techniques available in mobile devices, the actual content being viewed by users may be explicitly measured through in-program voting, betting, or purchase of utilities, Measurements may be implicitly measured. The measurement software may also run 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 to help content providers characterize their viewers in relation to important demographics and related consumer information Allows you to convert.

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

Since content providers can identify individual viewers, content providers may wish to implement targeted marketing programs aimed at maintaining their customers, increasing customer satisfaction, and promoting similar content . One means of building customer loyalty and expanding viewers involves rewarding customers with free access to broadcast content. For example, the content provider may want to allow the royal viewers of the content provider to allow them to view the first screened movie or to allow access to free music downloads. Thus, content providers may wish to provide coupons to these viewers of certain mobile TV programs, in order to encourage these viewers of certain mobile TV programs to view similar movies in conventional cinemas. Similarly, content providers may want to provide credits or coupons to the royal viewers in order to allow the royal viewers to view more of their programs on mobile TV. Also, content providers may want to perform cross-promotion where viewers are encouraged to view content on a home (possibly fixed) subscription-based television system, such as a DirecTV ^TM or Dish ^TM network .

Not only content providers 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 the point of sale (POS). Traditionally, merchants provided paper coupons and similar promotional items to their customers. The technical capabilities of mobile devices provide merchants with new means to reward customer loyalty. For example, merchants may want to provide royal customers with credits or coupons that they can use to view mobile TV programs. Such merchants may benefit from dual advertising benefits if credits or coupons allow customers to view programs including advertising from merchants that authorize credits or coupons.

Mobile TV broadcast service providers may also want to reward their customers with credits or coupons that allow their customers to view additional content or purchase products or services at a discounted price It is possible.

Other reasons for businesses, content providers, and mobile broadcast network providers to award credits or coupons to their customers include recognizing previous services or inducing future interactions; Compensating for unicast network traffic generated by service interaction activities; Compensating or providing future incentives for viewing the ads; And offering bonuses to premium customers. Also, credits or coupons may be awarded as part of customer loyalty programs (e.g., airline mileage, hotel points, meal tickets, etc.). Also, where consumer demographics can be accurately determined, credits or coupons may be provided to cross-sell exactly the products or services desired by such consumers.

A number of different mobile broadcast television services and broadcast standards are available or are 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 / from specific customer mobile devices and to perform mobile television programming using a separate broadcast network Broadcast to all mobile devices. In overview, the mobile broadcast service provider may send messages that contain information that allows the mobile device to generate the decryption keys necessary to receive a particular broadcast. The decryption keys may be configured to expire after a predetermined amount of time in order not only to enable the pay-per-view type services, but also to limit the economic impact of the 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 parts.

By way of example, the OMA BCAST standard uses a long-term key message (LTKM) that is sent to mobile devices over a unicast network to provide a constrained access key. The constrained access key is used by the mobile device to decrypt the traffic encryption key (TEK) included in encrypted form in short-term key messages (STKMs) that are regularly broadcast through the broadcast network. When decrypted, the TEK allows the mobile device to decrypt the encrypted broadcast content stream for a short period of time (e.g., two minutes). If the TEK has expired, access to the encrypted broadcast content will terminate unless a new TEK is obtained. In order to allow customers to view the entire programs, STKM messages are sequentially broadcast so that new TEKs can be obtained from these STKMs using long-term keys obtained from the LTKM.

Various embodiments are described below using the OMA BCAST standard technology and message names as an example. Other mobile broadcast standards use other similar messaging structures in message names and details, which is not important for various embodiments. For example, DVB-IPDC uses key management messages (KMMs) in a manner similar to the LTKM of the OMA BCAST standard and uses key stream messages in a manner similar to the STKM of the OMA BCAST standard , TEKs are used in a manner similar to the TEKs of the OMA BCAST standard. Similarly, the MediaFLO and CMMB use Encryption Management Messages (EMMs) in a manner similar to the LTKM of the OMA BCAST standard and use an Encryption Codeword Message (ECM) message in a manner similar to the STKM of the OMA BCAST standard ) And uses codewords (CW) in a manner similar to the TEKs of the OMA BCAST standard. Accordingly, the following description is provided by way of example and is not intended to limit the embodiments or the claims to the OMA BCAST standard. For convenience of reference, longer term rights management messages will be referred to herein as long decryption key messages or LTKM, and shorter duration decryption key delivery messages are referred to herein as short term decryption key messages or STKM And 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 have to pay in advance to become subscribers, or they have to pre-pay tokens for which the program may be redeemed for the content. For example, in a typical mobile broadcast TV system, customers can purchase one token per dollar they pay. Thereafter, an electronic wallet is activated in the mobile device, and tokens are deducted when users watch mobile TV programs. In the case where users have consumed all of their tokens, users must purchase new tokens before they can watch additional mobile TV programs.

Figure 1 is a process flow diagram illustrating a current framework in which mobile device users may subscribe to or purchase mobile TV broadcast services. In generating broadcast services or content, mobile TV service providers created a set of usage charging rules and agreed on a set of usage charging rules (step 100). Based on these charging rules, the service provider creates subscriber management keys (SMKs) and establishes service registrations (step 102). The service provider may receive (step 104) requests for service subscriptions from users or may receive a request to purchase pre-pay-per-view or pay-per-time tokens (108). The mobile broadcast service provider then sells the requested subscriptions or tokens to the requesting users (step 106, step 110), after which the mobile broadcast service provider sends the requested subscriptions or tokens to the user 'Lt; / RTI > message (step 112). The LTKM includes a long-term key for decrypting messages sent over the broadcast network. Typically, the long term key is typically subscription or service dependent. For example, users may subscribe at a basic level of membership that allows users to receive only basic cable broadcast channels, e.g., on their mobile devices. At this level of membership, users may not be able to view premium channels such as HBO ^® or ShowTime ^® . Typically, channel access control is facilitated by the use of different long-term keys between the basic channels and the premium channels.

The LTKM may also include service rules governing the use of the long-term keys 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 notify the device of one of the following modes of consumed content consumption; 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 transmitted over a unicast network in a message in which the long-term key is directed to a particular user's mobile device stored, for example, in the secure memory of the terminal or the security function on the smart card. The service provider then broadcasts the STKM (step 114). Continuously 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. All mobile devices in the service provider network receive a broadcast of the STKM stream and the associated encrypted content stream. However, not all users can decrypt all STKMs necessary to decrypt the content. The viewing privilege of a user is based on the service rules defined in the LTKM for each mobile device. Thus, if the service rules provided in the LTKM allow viewing of the program content, the mobile device decrypts the one or more TEKs to decrypt the content and displays 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 reduced from the mobile device electronic wallet (e.g., smart card) before the TEK is decrypted, Lt; / RTI > However, in LTKM, if the service rules do not grant access to program content, the terminal will not be allowed to decrypt the encrypted TEKs in the STKM stream to allow viewing of programming associated with the STKM stream.

However, current systems have limited capabilities to issue credits to users for promotions, or to create purchase incentives in the form of coupons or free tokens. Currently, the only way a mobile broadcast TV system provides credits to users is when coupons are sent to mobile broadcast TV users when the service is purchased. These coupons are sent to users as part of the purchase data sent to the users ' mobile devices along with the content. Since these coupons are distributed when users purchase services, coupons are targeted for particular users or groups of users. The tokens are also sold to users by service providers. However, these tokens are only approved at the time of purchase request, and current mobile broadcast TV systems lack a means to escape tokens that are approved from the intended purchase. That is, 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 carry a quantity of tokens that is different from the amount of requested tokens. Thus, the content provider or network service provider desires to provide more tokens than purchased to the royal consumer, and the system will not allow that to happen. These current limitations have made it possible for mobile broadcast service providers, network providers, and the like to allow their customers to use their services, to fill their unicast networks, to view their advertisements, Or incentives for shopping at their stores.

In order to overcome these limitations and enable new marketing uses of mobile TV broadcast services, various embodiment methods and systems may provide consumers with free or discounted merchandise or services, And credits that can be used in new revenue models to mobile devices. Content providers, mobile broadcast service providers, and advertisers may issue targeted credits (e.g., coupons and tokens) to mobile device users. These credits may then be used for complementary or discounted viewing of additional mobile TV content, or for purchase of products or services, thus allowing users to continue or increase their use of the mobile broadcast TV system To create incentives for doing 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. The credits may be issued with different types of restrictions that may be specified by the creator of the credit. Universal credit may be used to purchase any product or service anywhere. For example, universal credit may be used for online shopping, or to make purchases at the POS to purchase mobile broadcast TV services. Also, credit may be limited to program credits that may only be used to purchase programs from a mobile broadcast TV system. The credit may also be a specific credit that may only be used for purchasing a particular service or product, such as a merchant from which the credit originated, or products from the manufacturer.

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 a type of call. For example, users may use tokens to purchase pay-per-view (PPV) mobile TV programming to view on their mobile devices. Tokens may be provided to users free or discounted as a credit or promotion to create incentives for users to purchase products and services. There are two types of tokens for the measured consumption of broadcast services, as defined in OMA BCAST 1.0. The "user" tokens may be used to consume any item of content under the user ' s membership level, as defined in the service guide rules. The "service" tokens are limited to the programs available under the particular service of the user's member. Service Guides and Programming There is no value in some mobile broadcast TV systems, such as BCAST, which may not distinguish between membership and subscription from the viewing point of view. However, the flexible exchange of tokens or coupons for obtaining goods, services and / or programming may be more accurately handled in terms of membership, which may be associated with individual privileges.

Various embodiments allow coupons to be delivered to mobile devices to function as a type of currency that can be exchanged for a financial discount or a discount when purchasing products and services. Unlike paper coupons, which are often widely distributed through mail, magazines, newspapers, etc., coupons made available in various embodiments may be delivered to the mobile device via mobile TV broadcast services. Once delivered to the mobile device, the user may 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 specific time window, apply to any amount of purchased items, and may be configured independent of the actual price of the item. The credits may be exclusive (e.g., coupons that can not be combined), or may be non-exclusive (e.g., coupons that can be combined if the coupon providers are different). Also, the credits may be applied to a number of different purchase items (i. E., Individual products or services). The credits may be applied to products and services characterized by a set of purchasing data (e.g., a one-time program view, a product, or a single service), as well as in the case of subscription or consecutive purchase of services And may be applied to purchases characterized by multiple sets of purchase data. To support purchases of multi-data packages, credits may be configured to apply to subsets of purchase data, such as subscriptions. The 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 an overall process for generating credits, conveying credits to a user, and consuming credits on a mobile device. If the users employ their mobile devices to view mobile broadcast TV content (step 200), their use (e.g., level and type of usage) 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 the volume and selectivity of the broadcast content being viewed on users' mobile devices. Mobile TV service providers directly generate revenue for mobile broadcast service providers by benefiting from subscription fees or frequent use / consumption paid by one token purchase. Similarly, content providers benefit from increased demand for their content, which is higher advertising revenues and costs paid by mobile broadcast network providers. Also, as more and more users use unicast features of their mobile devices to participate in programs such as voting for users' favorite singers in TV singles competition shows, the number of cellular network providers providing unicast services More revenue is received by. The viewing habits of each user may then be analyzed by service providers, content providers, and advertisers so that highly valuable users may be targeted to deliver promotions and incentive credits or coupons. Thus, any one or more of the 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 services or products. If a valuable user or group of users is identified and matched with the appropriate credit type, the credits may be transmitted to the identified user's mobile device (step 204). As will be described in greater detail below, such credits may be conveyed by unicast or broadcast transmission methods. When such credits are received, the mobile device stores them in secure hardware, which may correspond to a removable smart card used in a mobile broadcast TV system, or may be secure memory on the terminal. The user may then redeem the 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 for purchasing 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. When a credit is received, the user may purchase the product online, for example, by clicking on the hyperlink URL provided with the credit to access the merchant's or manufacturer's web-store. Alternatively, the user may use coupons, such as other downloadable e-coupons, when presenting at a store, by presenting the mobile device at the POS and transmitting credits or electronically recording the use of the credits.

3 is a drawing of a network component of a mobile broadcast TV system illustrating participants involved in conveying credits to mobile devices. In a mobile broadcast TV system, credits may be generated by various businesses including broadcast service providers 30, third party businesses 50, and content providers 60. Broadcast service provider 30 is a company that typically provides 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 ( ^R) , AT & T ( ^R) , and T-Mobile ( ^R ). These companies receive audio, video, and website content from content providers 60. These contents are then transmitted to the broadcast network operator, which broadcasts the content over their mobile broadcast TV network 80 or unicast network 70. [ In some cases, the broadcast service providers 30 may also be cellular service providers, in which case they also provide a unicast network 70 that provides voice and data services to the mobile devices 40 And will operate. However, the broadcast service provider 30 need not be a unicast (e.g., cellular) network 70 provider. Although the unicast network 70 and the broadcast network 80 are operated by different entities, the mobile broadcast service provider 30 can still send messages to the mobile devices (e. G., Via the unicast network operated by another company) 40 or may be received from the 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. Third parties 50 may interact with users directly, such as when users are visiting their stores, or by broadcasting broadcast service providers 30 by representing advertisements in mobile broadcast TV programs. ≪ RTI ID = 0.0 > You can also interact with users through.

Content providers 60 may include companies that provide content and programs for broadcast through a mobile broadcast TV network 80. [ Also, 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 National Broadcasting Corporation (NBC), which provides news and entertainment content for broadcasting through 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 the unicast network 70 and the mobile TV broadcast network 80, the users can access the broadcast service provider 30 and the content providers (e. G. 60). For example, users may be maintained (via an unillustrated cellular data network) by their mobile device 40 or a computer coupled to the Internet via mobile broadcast service provider 30 and content providers 60 You can also access web sites that are Similarly, users may communicate directly with third parties 50 by accessing websites of third parties 50 via the Internet, or by moving to the facilities of third parties 50. [

Various embodiment methods and systems may be implemented on a number of delivery networks, such as SMS messages over a broadcast network 80, the Internet 90, a unicast network 70, Lt; / RTI > The users' mobile devices 40 may be targeted for distribution of credits based on their use in a mobile broadcast TV system. The credits may be passed directly or indirectly to the user's mobile device 40. The credits may be passed directly to the mobile device 40, for example, when a user makes a purchase on a business's web site via the Internet 90 using their mobile device 40. [ Such credits may also be transmitted to the mobile device (e. G., Via the out-of-band means), such as by an SMS, MMS or e-mail message delivered as part of an established Internet session, 40, respectively. For example, the user's mobile device 40 may receive credits from Starbucks ^® for a free cup of coffee that can be transmitted via out-of-band methods, such as by SMS, MMS, or email. Regardless of how the credits are delivered, the user's mobile device 40 may be able to redeem credits through the broadcast service provider 30 to receive pre-paid or discounted mobile TV programming.

The credits can also be used indirectly to targeted users, such as when a third party 50 submits credits to an intermediary such as a mobile broadcast service provider 30 for delivery to users < RTI ID = 0.0 >Lt; / RTI > Delivery of the credits to the mobile devices 40 by the broadcast service providers 30 may be accomplished using different methods. One method provides credits to users' mobile devices 40 when users communicate with the service provider 30 to purchase viewing tokens or subscribe to a broadcast service. Delivery of such credits may be accomplished through a service subscription response message sent by the broadcast service provider 30 in response to the mobile device 40 subscription request message. For example, if the mobile device 40 sends a subscription request message to the service provider 30 to request an extension or upgrade to the service subscription (e.g., from the base to the premium), the service provider 30 sends a subscription response And deliver third party 50 coupons to the user ' s mobile device 40 as part of the message. The delivery of such credits may be via the unicast network 70, or may be based on the user's values and habits. The second method may include communicating such credits to the user ' s mobile devices (40) in the event communication is not initiated by the user ' s mobile device (40). In this way, the service provider 30 may send (i. E. Push) credits to the user ' s mobile device 40 via a dedicated service provisioning message.

To support delivery, processing, and redemption of mobile TV system credits and coupons, various contracts and technology aspects may be adjusted prior to triggering targeted delivery of credits to users. The contractual aspects include establishing business rules relating to consumption and billing symmetries for credits and coupons as well as defining message interface specifications between third parties 50 and mobile broadcast service provider 30 . For example, coupon type A may be defined to be repayable for X minutes of viewing of certain purchased mobile TV programming, and coupon A expires at date Y. [ Another example is the free, reimbursable free of charge for a nominally-defined program viewing value of $ Z that is passed from the bank of the third party 50 to the bank of the service provider 30 as part of the transaction It may contain a token.

The technical aspects required to support mobile TV system credits and coupons may include using service provisioning messages to facilitate the acceptance and reimbursement of credits. In addition to communicating information between the mobile broadcast service provider 30 and the mobile devices 40, the service provisioning messages may be provided by the receiving mobile device 40 to accept the credits. Accordingly, the mobile broadcast service providers 30 may generate specific and targeted service provisioning messages for credit delivery, and may target such messages to, for example, mobile devices of royal users. When the mobile devices are ready to receive the credits, the mobile broadcast service provider 30 sends the credit to the targeted mobile device 40 via the unicast network 70, for example, with associated rules of credit (i.e., LTKM) May be transmitted.

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

In the illustrated embodiment, the mobile broadcast TV service provider 30 may send a report to the third party 50 describing the programming content to be broadcast in the near future (Figure 5 corresponding to message 500 in Figure 5) 4 302). This prior notification of programming to be broadcast allows third parties 50 to implement promotional campaigns such as not only evaluating programming for placement of advertisements but also providing credits or coupons to targeted consumers . When the third party 50 receives the broadcast programming report (step 502), the third party 50 determines that the third party 50 has received the credit in the form of coupons or tokens To the mobile devices 40 of the mobile device. To extend the credits to 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 includes the value of the credits to be delivered, the applicability of the credits to be delivered (e.g., redeemable programs, products, or services), the effective dates of the credits to be delivered, , ≪ / RTI > the details of the credits to be delivered. Upon receiving such a credit request message (step 304), the service provider 30 may send a credit response to the 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 the previously agreed contractual terms of consumption and payment (Step 506). In preparation for delivering third party 50 credits to the mobile devices 40, the service provider 30 may receive a credit response, which may be from a third party 50 (Step 308). The structure, elements, and parameters of the subscription response message are described in more detail below with reference to Figures 6-8 . That , The user mobile device 40 sends a request for the service to the service provider to unicast a request for service, such as to purchase viewing tokens, or to request or initiate a service reconciliation, such as pay-per-view tokens, (Step 402 of FIG. 4, corresponding to message 506 of FIG. 5). The mobile broadcast service provider 30 may receive and process the service request (Step 310), and in response may send an appropriate service provisioning response message to the mobile device 40 using the unicast or broadcast network 70 (corresponding to message 600 of FIG. 6) Step 312 of Figure 4. The service response may include not only third party credits, but also service adjustments requested by the user The user's mobile device 40 may receive the subscription response message via the unicast network 70, access the message content, store the credits in a memory of the mobile device 40, such as an electronic token parse (Step 404). The mobile device user may then use these credits for purchasing services or products as specified in the credits. The ways in which users can redeem credits stored in the mobile device 40 are described in more detail below with reference to Figures 15-20.

FIG. 6 illustrates an exemplary format and content of an embodiment join response message 600 suitable for conveying credits to mobile devices 40. FIG. 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 several components that may be classified as attributes and elements. 6, the subscription response message 600 may include optional attributes such as a request ID 602, a global status code 604, and an adaptation mode 606. The request ID 602 may be an identifier for the corresponding service request message 506. The request ID may identify the subscription response message 600 and correlate it with the correct service request message 506 to allow correct responses to arrive at the correct requestor. Using the request ID 602, the user's mobile device 40 can determine if an accurate service response has been received.

The global status code 604 may provide information about the overall result of the request in accordance with certain defined return codes. Exemplary return codes are described in more detail below with reference to FIG. By using the global status code 604, the mobile device 40 may determine whether the request has been successfully processed. That is, the global status code 604 may communicate the status of the service request message 506 sent by the user's mobile device 40 (i.e., failure due to success or error). For example, if the global status code 604 is present in the subscription response message 600 and set to a value of "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 value other than "0", this may mean that there was an error in the reception or processing of the request. Even if the service request message 506 has not been successfully processed, the mobile broadcast service provider 30 can not send the credits even if the mobile broadcast service provider 30 can not provide the specific service coordination requested by the mobile device. Lt; RTI ID = 0.0 > 600 < / RTI > If the global status code 604 is not present in the subscription response message 600, this may mean that there was an error with respect to the one or more purchase item elements 608 associated with the request. The purchase item element 608 is described in further detail below.

The optional adaptive mode element 606 may inform the mobile device 40 of an operational adaptation mode that may be generic or BDS-specific. For example, if the value of this attribute is set to "False ", it may indicate that adaptation mode 606 is generic. If the value of this attribute is set to "True ", it may indicate that adaptation mode 606 is BDS-specific. According to various embodiments, adaptation mode 606 may exist in subscription response message 600 only if global status code 604 indicates "success" and the underlying BDS is BCMCS.

The elements of the subscription response message 600 may further include essential purchase item elements 608 and operational elements of the DRM profile specification portion 610 or the smart card profile specification 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 about the requested requested item. For example, if the service request message 506 requested digital rights (e.g., a DRM profile) to play a particular content, and the subscription purchase was successful, the purchase item element 608 would have a validity end time 622, . The right validity end time 622 is described in more detail below with reference to the DRM profile portion 610. [ For a DRM profile or a smart card profile, to indicate why the request was not accepted by the mobile broadcast service provider 30, if there is a failure in the purchase or subscription request, an itemized status code (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, the purchase item element 608 may include an optional global ID reference attribute 614 and an optional itemized status code attribute 616. The purchase item element 608 may also include an optional bonus credit element 618 and a subscription window element 620. The global ID reference attribute 614 may be a specified 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 URI (Uniform Resource Identifier). The URI is, for example, a string of characters used to identify or name a resource on a unicast network. Such identification may enable interacting with representations of resources over the network using specific protocols. The itemized status codes may specify the status for each purchased item using the same returned codes, such as global status code 604, as described below with reference to FIG. 9 (As compared to the status code 604).

Credits may be transmitted from the mobile broadcast service provider 30 to the mobile device 40 by using an optional bonus credit element 618. [ For example, credit (e.g., coupon and / or token) data may be inserted into the bonus credit element 618 before the service response is sent to the mobile device 40. In this manner, users may receive credits from the mobile broadcast service provider 30 when they purchase services or subscribe to services. The type of credit that may be part of the subscription response message 600 may vary and may vary depending on the type of service requested (e.g., based on the usage of the mobile broadcast TV system and the user's hobbies), the identity of the user requested service, It may be bound to all. For example, zero or more stand-alone bonus credit sub-elements (also known as purchase data) may be present in the 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 user's membership level. Exemplary Embodiment Bonus Credits 618 message structures are described in further detail below with reference to Figures 7 and 8.

The required subscription window element 620 of the purchase item element 608 may include data related to the subscription or coupon valid time interval. The service provider 30 may use this element for time-based subscriptions and may include this element in the 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 an essential start time attribute (not shown) and an optional end time attribute (not shown). The start time attribute may include a Network Time Protocol (NTP) time stamp that specifies the start of the subscription. The end time attribute may include an NTP time stamp specifying the end of the subscription. In one exemplary embodiment, this attribute may be omitted for open-ended subscriptions.

The optional DRM profile specific sub-element 610 may include service and content protection DRM-profile specific portions. 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 right validity end time 622 attribute may be present to indicate the end time and date of validity of the LTKM associated with the purchased content and should be updated after the end time and date and the BSM accepts the request message. This field may be specified in the first 32-bit integer part of the NTP timestamps. For example, this attribute may be validated when the rights object (RO) is broadcast. Otherwise, this attribute is not required. In the presence of an optional element ROAP trigger 624, it may be expected that the mobile device 40 will use it to initiate one or more LTKM acquisitions.

The optional smart card profile specific element 612 may include service and content protection smart card profile specific portions. This part may be necessary to support the smart card profile, and may not be applicable to the DRM profile. The smart card profile specific sub-element 612 may include an optional LTKM element 626. The LTKM element 626 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 subscription response message 600 when the requesting mobile device 40 and the service provider 30 have agreed to "HTTP" (i.e., the Internet) as the LTKM delivery mechanism during the registration procedure.

FIG. 7A illustrates a diagram of a data architecture for an embodiment bonus credit element 618. FIG. 7A, the bonus credit 618 element includes a protection key 618a, a description 618b, pricing information 618c, promotion information 618d, an extension 618e, a purchase item reference 618f, A validation parameter 618l and a valid-from parameter 618d, a purchase channel reference 618g, a use clause 618h, a personal extension 618i, an ID 618j, a version parameter 618k, to < / RTI > parameters 618m. The protection key 618a may include an encrypted key that may be decoded based on the user ' s membership level, as described in the service guide rules. The description 618b may include a description of the product, a service or subscription being sold to the user 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: discount amount 619a and purchase type 619b. The amount of discount 619a may include one or more monetary values that 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 indicating 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 to be zero indicating that the item is free.

The purchase type table 619b shown in FIG. 7A may be a different type of purchase or credit transactions that may be used to populate the price information sub-element 618c when the subscription response message is sent to the user's mobile device 40 And values. The different types of purchase type values in the price table 619 may include one-time subscriptions, open-ended subscriptions, pay-per-time (" PPT) PPT playback to allow time-based consumption of live, non-live content, pay-per-play (PPP) play to allow a certain number of playbacks of non-live content Service tokens to allow time-based consumption of live content by using unrestricted playback, service tokens to allow unrestricted playback of back and non-live content, PPT live, service- Service tokens to allow time-based consumption of live content by allowing use of user tokens; user tokens to allow time-based consumption of live content by using PPT live, User token PPT playback to allow time-based consumption for non-live using user tokens, user token PPV playback by using user tokens, user token PPP playback by using user tokens, service Extra service tokens purchased to add to the service pals linked to a service / content SEK / PEK ID key group that may need a valid LTKM to use the tokens, a mobile broadcast service provider (e. 30) purchased extra user tokens that may be linked to IDs (this may or may not be a link to a particular service content and may require a valid LTKM to be used), a product from a store, Products, and products reserved for exclusive use) Non-Broadcasters Bit (ie, the real world) may contain the product.

Promotion information 618d may represent a discount / coupon that a user may obtain by purchasing a referenced purchase item. Extension 618e may identify a program, product, or promotion, or may include additional information about them. The purchase item reference 618f may be an identifier that identifies a particular purchase item associated with the promotional discount coupon. For example, the 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, purchase channel reference 618g may identify a content provider (e.g., 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 (e.g., Home Depot, Sears, etc.) where the product must be purchased.

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

The personal 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 may be used to validate the credit and prevent the user from falsifying the credit, such as a non-existent ID, an encrypted value, and the like. Coupon version 618k may include information for identifying a version of a coupon that may allow vendors to issue coupons for subsequent similar coupons with different terms and values over time. Thus, coupon version information may be used to support successive versions of the same type of coupon. The valid-from value 6181 may include information about the date and time when the credit becomes valid. A valid-to value 618m may include information about the date and time that the credit becomes invalid and may no longer be used. The valid-end value may be omitted if the coupon does not expire.

In addition, the 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 capability 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 using the URL.

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

An alternative embodiment of the coupon element 650 and its elements is shown in Figure 7B. The sub-elements of this alternative coupon embodiment identify the coupon, describe the coupon, indicate the price or discount offered by the coupon, identify the weight for purposes of combining with other coupons (described in more detail below) And includes information necessary to identify coupons, such as in the form of digital signatures. Exemplary information that may be included in the coupon object is: an identifier (ID) such as a globally unique identifier, a version number, a first moment effective date (valid starting date); A final moment effective date (effective end date) 652; A flag or value 664 indicating a coupon that must be verified by the issuer before being exchanged; An identifier 654 of the product or service to which the coupon applies; An identifier 656 for channels through which the product or service is to be purchased in order for the coupon to become valid; A description 655 of the coupon; An identifier of the provider of the coupon (e. G., The nature of the business issuing the coupon) 660; Multiple use weights 662, which will be described in more detail below with reference to Figure 27; An indication 666 of how quickly the coupon can be reused after the coupon has been exchanged; Price information 668 including comparison price or discount value information; An indication (670) of the intended item of purchase in which the coupon is valid; The monetary discount price (672) applicable when the coupon is exchanged; An identifier of the currency for 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 the 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 the issuing authority.

When an electronic coupon is delivered and processed as a separate coupon document or coupon object, the coupon object may be maintained outside the service guide. Nevertheless, the coupon object may include a pointer to a fragment of the service guide that identifies the information associated with the coupon. 7C shows the relationship between the coupon object 700 and the service guide 710. FIG. In particular, the coupon object 700 may include pointers 702, 704, 706 for specific information fields for the provisioning fragments 712, 714, 716 in the service guide 710 or in the provisioning fragment have. This pointer is in the form of globally unique pointers that do not change when the service guide is updated so that the information referred to as the coupon object 700 is always available via the pointers 702, 704 and 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 an encryption parameter 618n, a credit identifier 618p, and a multipurpose signature 618o. Encryption parameter 618n may be used to specify the 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 a coupon when the multipurpose signature 618o is delivered over a hostile network. The versatile signature 618o can be used to authenticate a coupon (e.g., an encrypted digest of all or part of the coupon field) and a coupon Lt; / RTI > In one embodiment, the multipurpose signature 618o may be used by the coupon issuer to generate coupons that can not be modified without detection (e.g., by using known public key cryptography methods). In one embodiment, the versatile signature 618o may be created using the X.509 signature layer so that the coupon recipient (e.g., mobile device and merchant) can verify that the coupon was issued by a specific authority , Will be described in more detail below. In this embodiment, the signature algorithm may be specified in an X.509 certificate.

FIG. 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 including the global status code "000 " may indicate that the requesting process was successful. The subscription response message 600 including the global status code "003 " may indicate that the requested purchase item is not known. 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 billing 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. Also, a "009" code may be used between different business entities 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 permitted 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 terms of the contract. 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, a "015" code may be used between businesses. The subscription response message 600 containing the global status code "016" may indicate that the same request has previously been 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-entering the request. A user subscription response message 600 containing global status code "021 " may indicate that the given information is not valid and can not be used by the system. In such a situation, the user may retest again and resend the request. The subscription response message 600 including the global status code "022 " may indicate that the requested key material and messages are not valid and can not be fulfilled. In such a scenario, the user may retest and retransmit the request if necessary. The subscription response message 600 containing the global status "031 " indicates that the user has attempted to employ a bonus credit 618 with a coupon, but may indicate that 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 " indicates that the user has purchased an available content object by employing an activated bonus credit (which the coupon has), but the coupon has already been used in a previous transaction, Lt; / RTI > 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 user's mobile devices 40 and may allow the user's mobile devices 40 to send credits to the user's mobile device 40 (40). Such delivery methods may be used by third parties 50 and mobile broadcast service provider 30 to deliver messages to all users using broadcast network 80 or to use the unicast network 70 to send messages To transmit credits to mobile devices 40 by communicating to specific users or groups of users. 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 Figures 10 and 11. [ The request pool messages may request credit purchase requests from the user ' s mobile devices (40). In another embodiment, to allow the user's mobile devices 40 to receive credits without taking explicit action, as described below with reference to Figures 13 and 14, And may be broadcast to the mobile devices 40.

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

10A is a process flow diagram of one exemplary embodiment method for bootstrapping users' mobile devices to receive free tokens using request pool messages. FIG. 11A is a message flow diagram of messages that may be exchanged between different mobile broadcast TV system components to deliver tokens in accordance with the method illustrated in FIG. 10A. This embodiment will be described below with reference to Figs. 10A and 11A.

To initiate the involuntary token purchase request, the mobile broadcast service provider 30 may send a request pool message to the user's mobile device 40 (step 314 of FIG. 10A associated with message 1100 of FIG. )). The request pool message 1100 may be transmitted via the broadcast network 80 or the unicast network 70. [ The request pool message 1100 is a message that initiates the credit transfer process described above with reference to Figures 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 pool of requests, the mobile device 40 may simply ignore the request pool message. However, if the user responds to the prompt by accepting the request pool (i.e., 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, which is related to message 1102 of FIG. 11A). The token purchase request message 1102 may be transmitted to the service provider 30 via the unicast network 70 or other network such as the Internet 90, as described above with reference to Figures 4 and 5. [ The token purchase request message 1102 may include information (e.g., an identifier) specified in the request pool message, or the token purchase request may include a request pool message 1100 And may designate a zero purchase request, 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 has not been successfully received (i.e., decision 318 = "NO"), a token purchase response with an error message may be sent to the mobile device 40 ), Message 1104). This error message may include the one or more codes and status messages described above with reference to FIG. If the token purchase request is successfully processed (decision 318 = "YES"), the mobile broadcast service provider 30 determines whether the user's mobile device 40 may receive (step 414) (Step 320 of FIG. 10A associated with message 1104 of FIG. 11A). The token purchase response message 1104 may include attributes and elements described in more detail below with reference to FIG. Following the transmission of the token purchase response message, the mobile broadcast service provider 30 may send an LTKM message to the mobile device 40, including conditions and terms in which free tokens may be used along with the tokens (Step 416 of FIG. 10A, which is related to message 1106 of FIG. The LTKM may also be transmitted via 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, which is related to the internal message 1108 of FIG. 11A). Optionally, the mobile device 40 may send an acknowledgment message to the mobile broadcast service provider 30 to indicate secure reception of the tokens (step 420 of FIG. 10A, which is related to message 1110 of FIG. 11A) . This confirmation message 1110 may also 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 one exemplary embodiment in which tokens are exchanged through token purchase request and purchase response messages, a common subscription request message, as a mechanism for receiving credits, such as receiving coupons instead of tokens, (I. E., Service requests). ≪ / RTI > 10B is a process flow diagram of one exemplary embodiment method for bootstrapping users' mobile devices to receive coupons via a service request using request pool 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 illustrated in FIG. 10B. Processes and messages having the same reference numeral are consistent with those described above with reference to Figures 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 Figure 10B corresponding to message 1103 in Figure 11B). Mobile broadcast service provider 30 may respond by sending a service response message to mobile device 30 (Steps 321 and 415 of FIG. 10B corresponding to message 1105 of FIG. 11B). The mobile broadcast service provider 30 then sends an LTKM message containing coupons (or other valuable items) (Steps 323 and 417 of Figure 10B, corresponding to message 1107 of Figure 11B). Mobile device 30 may also store 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. The token purchase response 1104 may include an optional request ID attribute 602 and an essential global status code attribute 604. [ As described with reference to FIG. 6, the request ID attribute 602 may be an identifier for the corresponding service request message. Thus, the request ID attribute 604 may identify the token purchase response message 1104 and correlate it with the correct token purchase request message 1102, to allow correct responses to reach the correct requester. Using the request ID attribute 602, the user's mobile device 40 can determine if an accurate token purchase response message 1104 has been received. As described above with respect to FIG. 6, the global status code 604 may provide information regarding the overall outcome of the token purchase request in accordance with certain defined return codes. Exemplary return codes are described in detail with reference to FIG. By using the global status code 604, the mobile device 40 may determine whether the request has been successfully processed or failed due to some error. That is, the global status code 604 may communicate the status of the service request to the user's mobile device 40 (i.e., failure due to success or error).

In addition, the token purchase response 1104 may include optional elements such as a DRM profile specific sub-element 610, a smart card profile specific sub-element 612, and a bonus credit element 618. The DRM profile specific element 610 and the smart card profile specific element 612 are mutually exclusive. Accordingly, the token purchase response message may include only one of the DRM profile specific sub-element 610 or the smart card profile specific sub-element 612. [ Service and content protection DRM profile specific sub-element 610 may be necessary to support a DRM profile and may not be applicable to a smart card profile.

The DRM profile specific sub-element 610 may include optional elements 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 join response message 600 except for some differences. If the token purchase is successful, the token purchase response message 1104 may include a ROAP trigger 624 as an additional payload. The mobile device 40 may initiate one or more token acquisitions using this ROAP trigger 624 (i.e., 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 includes an ROAP Registration triggers. The mobile device 40 may then be prompted to initiate the registration process with the service provider 30 and then may resend the token purchase request message 1102 once the mobile device 40 has successfully registered .

The token purchase response message may include an optional token grant element 1202 and an LTKM element 626. [ The token acceptance element 1202 may include a number of attributes, such as information about accepted tokens in response to the token purchase request message 1102. [ These attributes may include type 1204, amount 1206, and billing 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 accepted and their assigned values include the reserved tokens (value 0), the tokens for the DRM profile (value 1), the service token for the smart card profile added to the live PPT Perth (Value 2), service tokens (value 3) for the smart card profile added to the playback PPT Perth, user tokens for the smart card profile added to user Perth associated with the service provider 30 ID (value 4 ), Tokens (values 5 to 127) reserved for future use, and tokens (values 128 to 255) reserved for exclusive use. Both attributes 1206 may include information specifying the number of tokens approved in the token purchase transaction. For the type attribute 1204, the value specified in the attribute may correspond to the number of approved tokens. The billing type attribute 1208 may include information about the type of billing to be associated with the token purchase transaction. The charging types include preliminary (value 0), prepayment (value 1), postpay (value 2), reserve for future use (values 3-127), and reserve (values 128-255) for exclusive use 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" (i.e., 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 includes an optional bonus credit element 618, which may be sent to users, such as tokens or coupons May also be included. For example, the credit (i.e., 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 manner, users may also receive credits from the mobile broadcast service provider 30 when their mobile devices 40 respond to the request pull message sent by the mobile broadcast service provider 30 have. The credit type, which may be part of the token purchase response message 1104, may be changed, for example, the type of token being pushed to the users, the request pool message 1100, The identity of the user in response to the purchase request message 1102 (based on usage of the system), or both. For example, zero or more stand-alone 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 user's membership level. Exemplary Embodiment Bonus Credits 618 message structures are described in further detail with reference to Figures 7 and 8.

FIG. 13 illustrates a process flow of one exemplary embodiment for bootstrapping users' mobile devices 40 to receive free tokens using token acknowledgment 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. This embodiment will be described with reference to both Figs. 13 and 14. Fig.

The mobile broadcast service provider 30 may send a token acknowledgment push message to the mobile device 40 (step 321, message 1400) to initiate delivery of the tokens to the mobile device 40. The mobile device 40 may receive and process the token acknowledgment push message (step 413). The token acknowledgment push message informs the mobile device 40 that the LTKM is to be transmitted so that the mobile device 40 can prepare to receive the credits in the LTKM. Following the token acknowledgment push message 1400, the mobile broadcast service provider 30 may send the 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 memory, such as the mobile device security function 90 (e.g., smart card memory) (Step 418, internal message 1108). The mobile device 40 may respond with an acknowledgment message to the mobile broadcast service provider 30 (step 420, message 1110) to indicate that the LTKM and free tokens have been successfully received and stored. Alternatively or alternatively, if the tokens are not successfully stored in memory, the mobile device 40 may include that information in an acknowledgment message (not shown). The mobile broadcast service provider 30 may receive (step 324) an acknowledgment message 1110 and perform the appropriate steps based on the content of the message. For example, if the confirmation message 1110 indicates that the tokens were successfully received by the mobile device 40 and indicate that they have been stored, the service provider 30 may not perform 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 sends the LTKM 1106, Such as retransmitting the message to the user.

When credits, such as free tokens or coupons, are delivered to the mobile device 40, the user may use them to purchase TV programs, services, or products. According to various embodiments, different methods for repaying the credits may be employed. One exemplary reimbursement method includes broadcasting an STKM, which credits may be used to purchase service content only from a particular mobile broadcast service provider 30. Another example is to use the unicast network 70 to allow the mobile device 40 to reduce certain credits from on-board e-mail services (implemented in secure memory or smart cards on the terminal) as part of the payment for the purchase Lt; RTI ID = 0.0 > LTKM < / RTI > The LTKM Perth Mode message is a message that contains instructions that cause the mobile device to reduce credits from its electronic fares. Another example involves broadcasting an STKM null program message, which is a message that instructs the mobile device 40 to reduce certain credits from its electronic pay as part of a payment. Each of these credit redemption methods is described in more detail below with reference to Figures 15-20.

15 is a process flow diagram of an exemplary embodiment for redeeming credits using STKM broadcasts. 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. This embodiment will be described below with reference to Figs. 15 and 16. Fig.

According to various embodiments, credits delivered to or pushed to the mobile device 40 include credits that may be redeemed only for purchasing free or discounted programs or content from the mobile broadcast service provider 30 It is possible. In such a scenario, the mobile broadcast service provider 30 sends an STKM stream (message 1600), nominal or promotional programs, which may also be purchased using credits stored in the mobile devices 40, The message 1601 may broadcast a content stream 1601. The message 1600 includes a broadcast delivery of the STKM stream 1602. The message 1601 may be a continuous stream, To the mobile device 40. The 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 (Step 420). The broadcasted STKM stream 1600 is broadcast to the broadcast network 80, All mobile devices 40 that have received the STKM may have access to the encrypted content stream (messages 1601) associated with it, 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 the mobile devices 40. For example, the LTKM rules that may be used are transmitted with the credits as described above with reference to Figures 10-14 In the case where the mobile device 40 receives the STKM stream 1600, (Decision 422), it may determine whether the LTKM rules allow access to the STKM stream 1600 (decision 422), by retaining it in the vendor device security function 90 (step 422). If the mobile device 40 determines that the LTKM rules do not allow access to the STKM stream (decision 422 = "NO"), the mobile device 40 may ignore the STKM stream (not shown). If the LTKM rules allow access to the STKM stream (i.e., decision 422 = "YES"), the mobile device 40 decrypts one or more TEKs from the STKM stream for the availability of credits in Perth (Step 424, internal message 1604) from the credit card. The mobile device 40 may then use the TEKs to decrypt at least a portion of the encrypted content stream (message 1601).

For example, the message stream 1601 may carry the 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 for accessing such programs may access and decrypt the HBO® program (messages 1601). Other mobile devices 40 that have not received the LTKM and the credits required for this promotion may not have access to the content associated with this STKM stream 1600. [

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

17 is a process flow diagram of one exemplary embodiment that allows users to spend credits to purchase a service or product from an merchant. 18 is a message flow diagram of messages that may be exchanged between system components to implement the steps as shown in Fig. This embodiment will be described below with reference to both Figs. 17 and 18. Fig.

In this exemplary embodiment, the promotional credits that are transferred from the LTKM to the mobile device 40 may be used to purchase products while shopping at an merchant or vendor web site. The process of receiving and storing credits is described above with reference to FIG. 10 or FIG. Such credits may be used to pay for services or products while shopping, such as physically shopping at a vendor's location (i.e., POS) or online shopping, or to receive discounts for services or products have. The user may initiate a shopping session with the merchant 50 via his / her mobile device 40 (steps 428, 508, messages 1800). The user may indicate a desire to terminate the purchase and may transmit information regarding coupons or credits stored in the mobile device 40 from the mobile device 40 to the merchant 50 (message 1802) . This message may be transmitted over the Internet in an online shopping session or may be transmitted to the merchant's POS system via various known transmission methods including, for example, a near field communication (NFC) link, a displayed bar code, (40). The merchant 50 may determine whether the credits presented may be used as part of the payment for this transaction (decision step 510). If the credits can not be used for payment for this transaction, the merchant 50 may allow the user to pay using other means of payment, such as using a credit card (not shown). However, when the merchant 50 determines that the user's credits or coupons can be used (i.e., decision 510 = "YES"), the merchant 50 sends a payment request to the mobile broadcast service provider 30, (Step 512, message 1804)). This payment request message 1804 may be transmitted over the Internet 90 or other network and may identify presented coupons, the user, and / or the mobile device 40. Upon receipt of the payment request (step 330), the mobile broadcast service provider 30 may generate an LTKM parse mode message and send it to the user's mobile device 40 (step 432) )). The LTKM persuade mode message 1806 may be sent to the user 40 using the unicast network 70 and the LTKM persuade mode message 1806 may be sent to the user 40 by the user's mobile device 40 Commands. The mobile device 40 may receive LTKM persuade mode message 1806 (step 432) and may reduce the credits from the electronic persk based on the LTKM rules (step 434, internal message 1808 )). If the credits have not been fully or successfully reduced, the mobile device 40 may send a signal to the mobile broadcast service provider 30 (not shown). The mobile broadcast service provider 30 may retransmit the LTKM Perth mode (not shown) if the credits have not been fully or successfully reduced from the mobile device 40 Perth. However, if the credits have been successfully reduced, the mobile device 40 may send an acknowledgment message to the mobile broadcast service provider 30 (step 426, message 1810). This confirmation message 1810 may be transmitted via the unicast network 70. The mobile broadcast service provider 30 may receive the confirmation message 1810 (step 334) and send a payment response message to the merchant (step 514) that the merchant may receive over the Internet or other network 50) (step 336, message 1812). The payment response message 1812 may provide the merchant 50 with information that the credits have been successfully reduced from the user's mobile device 40 par. The merchant 50 may complete the transaction with the user. The processing of the credit reimbursement between the mobile broadcast service provider 30 and the merchant 50 may occur at the time of sale with the transmission of the payment response message 1812, for example, or at a later time (steps 338, 516 )).

In one exemplary 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 services. Because the STKM null program message is broadcast to all terminals, only the mobile device involved in the shopping transaction must be affected by this particular payment message. This is ensured by carrying a unique shopping transaction ID in the STKM null program message. All other mobile devices that are not involved in the shopping transaction by users may simply ignore this STKM message. 20 is a message flow diagram of messages that may be exchanged in the method illustrated in Fig. This embodiment will be described below with reference to both Figs. 19 and 20. Fig.

The process of receiving and storing credits is described above with reference to FIG. 10 or FIG. As described above, credits stored on the mobile device 40 may be used to pay for services or products while shopping at a vendor's location (POS) or shopping online. The user may initiate a shopping session with the merchant 50 via his / her mobile device 40 (steps 428 and 508 of FIG. 19 corresponding to message 1800 of FIG. 20). The user may indicate the desire to terminate the purchase or may transmit information regarding coupons or credits stored in the mobile device 40 from the mobile device 40 to the merchant 50 1802). The message may be transmitted over the Internet in an online shopping session or may be transmitted to the merchant's POS system via various known transmission methods including, for example, a near field communication (NFC) link, a displayed bar code, (40). The merchant 50 may determine whether credits may be used to pay for the transaction (decision 510). In the event that credits can not be used to pay for this transaction (step not shown), the merchant 50 may allow the user to pay using other means of payment, such as using a credit card. However, if the merchant decides that the user may be able to pay using the credits (i.e., 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 sent by the Internet 90 or another network and may identify the offered coupons, the user, and / or the mobile device 40. Upon receipt of the payment request (step 330), the mobile broadcast service provider 30 may broadcast an STKM null program message to the mobile device 40 (corresponding to message 2000 in Figure 20) Step 331 of FIG. 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. The mobile device 40 may receive the STKM null program broadcast message 2000 (step 438) and use its keys in the LTKM associated with the credits stored on the mobile device 40 to encrypt To determine whether the LTKM rules allow access to the STKM null program broadcast message 2000 (decision 422). If the LTKM rule allows access to the STKM null program message 2000 (i.e., decision 422 = "yes"), the message may be sent to Perth where the credits are stored (internal message 2002) May be reduced from Perth (step 434). If the credits are decreased, a confirmation 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 via the unicast network 70. The mobile broadcast service provider 30 may receive an acknowledgment message 1810 (step 334) and send a payment response message to the merchant 50 19, step 336). The payment request message 1812 may be transmitted via the Internet 90 or another network. The merchant 50 may receive a payment response to inform the merchant 50 that the credits have been successfully reduced so that the merchant 50 may terminate the sale (step 514). The credit redemption may then be processed between the mobile broadcast service provider 30 and the merchant 50 via any known financial transaction mechanism (steps 160 (FIG. 19) corresponding to message 1606 of FIG. 20 338, 516).

The mobile device 40 may ignore the message if the STKM null program message 2000 should or can not be accessed by the mobile device 40. [ Accordingly, the credits will not be reduced and an acknowledgment message 1810 will not be sent to the service provider 30. The mobile broadcast service provider 30 will send a payment response message 1812 to inform the merchant 50 that the credits have not been delivered since the mobile broadcast service provider 30 has not received the confirmation message. In such a scenario, the merchant 50 may deny credits or coupons, and may ask the user to use another form of payment for the 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 invention is not limited to this form of credits. 21 is a process flow diagram of one exemplary method for identifying and deleting expired coupons from an electronic coupon of the mobile device 40. [ The coupon may be received by the mobile device 40 (step 2100) and 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 from the broadcast service provider 30 in the form of an LTKM or an STKM. If the coupon is accessed in response to the LTKM or STKM, the mobile device 40 may determine whether the coupon has expired prior to allowing the coupon to be used (decision 2108). If the coupon has expired (i.e., decision 2108 = "YES"), the coupon may be deleted from memory (step 2112) and a report of expiration of the expired coupon may be received from the mobile broadcast service provider 30 (Step 2114). Such an expired coupon deletion report may be transmitted via the unicast network 70. If the coupon has not expired (i.e., decision step 2108 = "NO"), the coupon may be applied for the purchase based on the received LTKM or STKM as described above (step 2110).

22 is a process flow diagram of one exemplary embodiment method for identifying and deleting coupons used. The coupon may be received by the mobile device 40 (step 2100) and 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 from the broadcast service network 30 in the form of an LTKM or an STKM. In the event that the coupon is accessed in response to the received LTKM or STKM, the mobile device 40 may determine whether the coupon has been previously used or previously copied before the coupon is reduced to pay for the purchase transaction 2200)). This determination may allow coupons to be defined so that the coupons may be made available only once by a user, each time only by each user, or may be made available multiple times during a promotion period, To be used according to other usage patterns that may be possible. If the coupon was used or previously copied (i.e., decision 2200 = "YES"), the coupon may be deleted from memory (step 2112) (I.e., decision step 2108 = "NO"), the coupon may be sent to the mobile broadcast service provider 30 (step 2114). If the coupon has not been previously used or copied The coupon may be applied for purchases based on the received LTKM or STKM as described above (step 2110).

While the foregoing embodiments are directed to mobile devices that communicate with a mobile broadcast service provider through a unicast network, other communication links may be used. For example, such messages may be communicated to the server pool within the mobile broadcast service provider network via any network communication without departing from the invention and the claims.

It will be appreciated that the embodiments described above may be used to deliver coupons or tokens to mobile devices over long term decryption key messages (e.g., LTKM), to reduce coupons or tokens via short-term decryption key messages (e.g., STKM) But the claims may also include implementations using dedicated coupon transaction messages that are not the current part of known mobile broadcast standards. In the event that such standards are modified to include dedicated coupon transaction messages, such messages will be processed similar to the short-term and long-term decryption key messages described herein and will include a plurality of these elements.

By using public key cryptography and electronic signature coupons, the user and / or retailer can each verify that the coupon is unique without contacting the original publisher, or store a copy of all issued coupons. In an embodiment, a coupon may be issued and used by only one person or by a group of users, or may not be reused by other users. In this case, the digest of the multipurpose signature 618o not only covers the entire content of the coupon object, but also covers the account identification of the authorized user (or user-group) for use of the coupon and other aspects of the coupon record It is possible. If the coupon is authenticated using the digital signature technology, it will be easily detected by a third party trying to submit a coupon that has never been issued since this signature will not be verified using an unauthorized account identification.

In an embodiment, the multipurpose signature 618o may be formed using the X.509 signature layer. X.509 is a public key infrastructure that specifies, amongst other things, the authentication path validation algorithm and the format for the public key certificate, which allows the recipient to verify that the signature was generated by a certificate trusted by the root X.509 certificate. It is a well-known ITU-T standard. In summary, the digital signature is obtained through a chain of certificates, each certificate specifying a higher-level certificate, and the chain of certificates is pending with a trusted X.509 certificate stored by the coupon redeemer. By reverting the X.509 privilege, the root X.509 authority can pass on the child certificate to authenticate other companies that will issue the valid coupons. In this manner, the coupon validation entity may distribute the coupon signature certificate to the companions who desire to issue the coupon, and the companies that desire to issue the coupon may then send an individual coupon A self-certificate may be issued to a unit or department. A merchant point-of-sale (POS) system or merchant server 50 presented with coupons validated by a digital signature using an X.509 signature layer may be used to identify a coupon without having to establish a trust relationship with an individual coupon issuer You can use the cached authentication certificate provided by X.509 authority. As described above, the use of the digital signature formed using the X.509 signature layer enables the merchant system to validate the coupon when the merchant system trusts the X.509 authority, Simplify repayment. This allows the merchant system to verify the coupon without communicating with the coupon issuer.

In embodiments, coupons with digital signatures may be generated and broadcast to the mobile device 40 via a mobile multimedia broadcast network. 23 shows a method of an embodiment for broadcasting coupons with a signature. In the embodiment, the merchant server 50 generates a coupon template (step 2302) including access information for coupon acquisition such as UR, L and coupon ID number, and transmits the coupon template to a mobile broad To the cast provider 30 (step 2304). The mobile broadcast provider 30 may receive the coupon template from the merchant server 50, encrypt it, and broadcast it (step 2306). The mobile device 40 may receive the encrypted coupon template from the broadcast transmission (step 2308). The mobile device 40 may decrypt the coupon template by using the TEK (step 2310). As described above, the TEK is retrieved based on the LTKM and the 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, the mobile device 40 may receive a TEK (via the LTKM and STKM method) that allows the device to decrypt the coupon template . If the mobile device is not part of the intended group of coupons, the mobile device 40 may not have a corresponding TEK and therefore will not decode the coupon template. Once the coupon template is decrypted, the mobile device 40 requests the available electronic coupon by using the Internet 90 over the unicast network and sends the electronic coupon to the web site hosted by the merchant server 50 using coupon access information (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 an electronic coupon (step 2314). Merchant server 50 may send a request for device identification information, as well as any coupon data not delivered in the initial request, to the mobile device 40 over an open Internet connection (step 2316). The 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 the merchant server 50 (step 2320). This mobile device identification information may be any form of information that identifies the device and / or the user to the merchant server 50. Examples of such information include a device identifier (e.g., a MAC ID), a device phone number, a user account number, a membership number, a user name, a password stored in a device memory known to the merchant server 50 Number (PIN)) and the like. During a transaction, one or more of these device identifiers may be requested to be submitted by the mobile device.

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

Merchant server 50 may use the identification and coupon data to generate coupons that include digital signatures (step 2324). The digital signature digest may include a request for device identification information and a coupon ID. As discussed above, the digital signature may be generated using a certificate with an X.509 signature layer associated with returning to root X.509 authority. As described below, the digital signature along with the device information and coupon ID may be used at the POS to verify that the coupon is authentic before receiving the coupon. The confirmation method at the POS will be described in more detail below with reference to Fig. The merchant server 50 may send the signed coupon to the 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 a unicast network (step 2330). Alternatively, the merchant server 50 may send the signed coupon directly to the mobile device 40 via an open communication link over the Internet 90. The mobile device 40 receives and stores the signed coupon (step 2330) and may notify the user of the receipt of an electronic coupon that may be used at the time of the transaction (step 2332).

In an alternative embodiment, instead of providing a URL, the coupon template may include a different communication indicator or address, such as a telephone number. In this embodiment, the mobile device 40 may communicate with the merchant server 50 to exchange device identifications over the telecommunication network and receive signed coupons, for example, using SMS or MMS communication methods have.

24 shows another embodiment method in which the merchant server 50 may generate a signed electronic coupon for broadcasting to the mobile device 40 without encrypting the broadcast coupon. In this embodiment, the merchant server 50 generates a coupon with a digital signature including the coupon data, the coupon identification number, and the intended recipient's mobile device identity data (if known) using the conventional signature method 2402) and transmits the signed coupon to the mobile broadcast provider 30 to be broadcasted (step 2404). As discussed above, the digital signature may be generated using a certificate with an X.509 signature layer associated with returning to root X.509 authority. As in the previous embodiment, the mobile device identity data may include any one or more device identifiers such as a device MAC ID, a telephone number, a PIN, an account number, or a group number. The group number may be assigned to the mobile device 40, for example, assigned to or assigned to a group of mobile devices or users (i.e., group ID) via contact or transaction with an affiliate. For example, the merchant may have a regular customer reward program that the user can register with, and may receive a group identifier that may be stored in the mobile device to receive the coupon. In this embodiment, the merchant issues to broadcast an electronic coupon signed with a customer reward program identifier, so that only registered customers will receive redeemable coupons over the broadcast network.

The mobile broadcast provider 30 may receive the signed coupon from the merchant server 50 and broadcast it as part of the regular broadcast transmission (step 2406). In this exemplary embodiment, the digital signature verifies the coupon usage by the user and the merchant server so that only certain mobile devices receive and process the coupon, so before the coupon is broadcast, the signed coupon is sent to the broadcast provider 30 ). ≪ / RTI >

The mobile device 40 may be pre-registered with the merchant server 50 in order to receive and decode the digitally signed coupon from the merchant server 50. [ As part of the pre-registration, the merchant may provide a decryption key to the storage of 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 verification certificate. Additionally, during the pre-registration process, the mobile device 40 may share device data with the merchant server 50. Merchant server 50 stores and uses such device data received during pre-registration to generate coupons that contain data with digital signatures containing device data along with coupon data. This method enables the creation of an electronic coupon that can only be used by a particular mobile device since it can only be verified when the digital signature is with the device data. This allows coupons to be presented to individual users or subgroup users to be broadcasted in an unencrypted manner over the broadcast network 80. [

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

If the received device data in the signature matches the mobile device data (i.e., decision step 2414 = "YES"), the mobile device 40 may store the coupon in the memory of the mobile device 40 (step 2416) The user may be notified of the reception of the electronic coupon that can be used at that time (step 2418). If the device data obtained from the decrypted signature does not match the mobile device 40 data (i.e., decision step 2414 = "NO"), the mobile device 40 determines whether the coupon is intended for the mobile device 40 The coupon may be ignored (step 2420). In addition, if the mobile device 40 does not allow the requested decryption key to decrypt the coupon signature, the mobile device 40 may ignore the received coupon. In a manner similar to providing a provable electronic coupon to specific users or groups of users via 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 at various ways. For example, depending on the form of the coupon, the item may be purchased at a discount at the POS or may be free. 25 illustrates a method of an embodiment for redeeming coupons signed during a purchase transaction at a POS. During the purchase transaction (e.g., during "check out"), the user may provide the POS system 95 with a mobile device that has stored the signed coupon. The mobile device 40 and the POS system may negotiate with the communication link as well as using a well known near field communication (NFC) link over which the mobile device 40 may communicate with the device identity data Electronic coupon data may be transmitted (step 2502). The POS system 95 receives the signed coupon and device identity data (step 2504) and may send a confirmation request of the signed coupon to the merchant server 50 (step 2506).

The confirmation request message from the POS may include a coupon signature, a coupon ID, and received device identity data. The merchant server 50 receives the confirmation request message (step 2508), decrypts the signature (step 2510), compares 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 is generated using an X.509 signature certificate, the merchant server 50 may also verify that the coupon was issued by an entity trusted by the root X.509 authority and is therefore due to a trusted transaction . If the digital signature is correctly decrypted (confirming that the issuer is trusted) and the coupon ID and device identity data retrieved from the signature match those received from the POS system of the confirmation request message (i.e., decision step 2510 = "YES"), The merchant server 50 may check the coupon (step 2514).

As part of the coupon validation, the merchant server 50 may also look up the coupon ID in the coupon's database (e.g., a coupon object list (dead coupon object list) that is no longer available as described below) If the coupon is verified by the digital signature and the data records indicate that the coupon has not already been used and has not expired, it is possible to determine if the coupon has already been redeemed and check the coupon field to determine if the coupon has expired. , The merchant server 50 may send a confirmation message to the POS system 2516. The POS system may receive the confirmation message 2518 and apply the coupon to the purchase transaction 2520 ). The POS system selectively transmits a coupon use message to the merchant server 50, (Step 2522) to the merchant server 50. The POS system may also send a coupon cancellation message to the mobile device 40 (step 2526). When the merchant server 50 receives the coupon use message (Step 2524), and record that the coupon ID has been redeemed. The mobile device 40 may receive the cancel 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 2510 = "NO"), or if the coupon has expired or has already been redeemed, the merchant server 50 may reject the coupon (Step 2530), and may transmit a rejection message to the POS system (step 2532). The POS system may receive the rejection message and reject the coupon during the purchase transaction (step 2534).

Figure 26 illustrates an exemplary method for canceling previously redeemed or expired, digitally signed coupons. When confirming or rejecting the signed coupon, the merchant server 50 optionally transmits a coupon cancellation message to the mobile device 40 (step 2602) to indicate to the mobile device 40 that the coupon should not be used for another purchase transaction (40). The coupon cancellation message may be transmitted to the mobile device 40 using unicast, such as SMS, email, MMS or other conventional methods. The mobile device 40 may receive the coupon cancellation message (step 2604). As part of receiving a coupon cancellation message, the mobile device 40 may check the digital signature associated with the cancellation message and confirm the authorization before deleting the associated coupon data from the memory. This digital signature may be formed using the X.509 signature layer so that the mobile device 40 can verify that the revocation message was sent by an authorized authority.

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 may delete the coupon in the mobile device memory in response to the merchant server 50 The cancellation may be accepted (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 who want to redeem the same coupon multiple times .

In order to ensure reliable operation of the coupon distribution and redemption system, merchant server 50 may check whether a coupon cancellation message acknowledgment has been received in decision step 2608. [ If the coupon cancellation approval message has been received (i.e., decision step 2608 = "YES"), the process of confirming and redeeming the coupon by the merchant server 50 may terminate (step 2616). However, if the coupon cancellation authorization message is not received (i.e., decision step 2608 = "NO"), the merchant server 50 sends the coupon to the database that is accessible to the server or maintained by the server Dead coupon object "(step 2610). Creation of a dead coupon object in the server accessible database allows the server to recognize that the coupon has been previously redeemed if the coupon is presented to the merchant for the second time. Thus, as part of the coupon validation process described above with reference to step 2514 of FIG. 25, the merchant server 50 also checks the dead coupon object database to determine whether the coupon has been included in the list as redeemed It is possible. In an embodiment, the creation of a dead coupon object causes the merchant server 50, if expired in step 2612, to prompt the merchant server 50 to determine whether the coupon continues to be included in the data ace, such as a dead coupon object database, . ≪ / RTI > If the merchant server 50 is continuously tracking the redeemed coupon at that point (i.e., decision step 2614 = "YES"), the merchant server returns to step 2602 to send another coupon cancel message to the mobile device 40 You may. If the merchant server 50 does not estimate the redeemed coupon (i.e., decision step 2614 = "NO"), the coupon verification and reimbursement process by the merchant server 50 may terminate (step 2616). This process may also be terminated if the coupon itself expires because the 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 how coupons may be combined and, if so, to what extent they may be combined with other coupons And may include a weight. The merchant may build rules for use by the POS system to use coupon weights assigned to determine whether the combination of multiple coupons is allowed. The merchant server 50 may implement the rules such that the combination of these 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, a 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 a number of coupons are presented to the POS system, the sum of the weights assigned to the coupons is greater than one, the merchant may not allow the combination of such coupons. 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 unity. 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 also allows the merchant server to validate or accept coupons without having to contact the original coupon issuer (s).

Figure 27 illustrates an embodiment of a method for determining whether a combined use of a plurality of 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 validation request from a POS system containing 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 a 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 " (i.e., decision step 2710 =" YES "), merchant server 50 may prove 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" (i.e., decision step 2710 = "no"), merchant server 50 may reject the combined use of two or more coupons for one purchase transaction 2712). Acceptance or rejection of the combined coupons may be communicated to the POS system with an acknowledgment or rejection message similar to that described above with reference to FIG.

Typical mobile devices 40 suitable for use with various embodiments will have components in common in FIG. For example, one exemplary mobile device 40 may include an internal memory 192, a display 193, and a processor 191 coupled to the speaker 199. The mobile device 40 may also have a cellular telephone transceiver 195 coupled to the processor 191 and / or an antenna 194 for transmitting and receiving electromagnetic radiation coupled to the wireless data link. In some implementations, the processor 191 and portions of the memory 192 and the transceiver 195 used for cellular telephone communications provide a data interface over a wireless data link and are collectively referred to as an air interface . Mobile devices typically also include a keypad 196 or mini 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 (s), which may be configured to perform various functions including the functions of the various embodiments described herein by software instructions Or chips. In some mobile devices, a number of processors 191 may be provided, such as a processor dedicated to executing wireless communications functions and a processor dedicated to executing other applications. Typically, the software applications may be stored in the internal memory 192 before they are accessed and loaded into the processor 191. In some mobile devices, the processor 191 may include sufficient internal memory to store application software instructions. The mobile device 40 may also include a separate memory chip 190, such as a smart card for storing information related to credits, tokens, and coupons, such as an electronic coupon according to 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, the internal memory 192 may be a non-volatile memory such as a flash memory or volatile memory, or a mixture thereof. For purposes of this description, a generic reference to a memory may be provided to processor 191, including internal memory 192, memory chip 190, removable memory plugged into a mobile device, and memory within processor 191 itself. ≪ / RTI >

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

The method descriptions and process flowcharts set forth above are provided by way of illustration only and are not intended to be indicative or is not intended to represent that the steps of the various embodiments should be performed in the order presented. As will be apparent to those skilled in the art, the order of the steps in the above-described embodiments may be performed in any order. Words such as "after "," after ", "next ", and the like are not intended to limit the order of the steps; These words are simply used to guide the reader through a description of the methods. Also, any reference for asserting elements using, for example, " a ", "an ", or" the ", as a single entity, should not be construed as limiting the element to a single entity.

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 of both. 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 logic, logic blocks, modules, and circuits described in connection with the aspects disclosed herein may be implemented or performed with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC) , 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. The processor may also be implemented as 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 a circuit 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. When implemented in software, the functions may be stored on or transmitted via one or more instructions or code on a computer-readable medium. The steps of a method or algorithm disclosed herein may be embodied in an executed processor-executable software module that may reside on a computer-readable medium. Computer-readable media includes both communication media and computer storage 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, and not limitation, such computer-readable media can comprise instructions or data structures that may be accessed by a computer, such as RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, But is not limited to, any other medium that may be used to carry or store the desired program code in the form of instructions. Also, some connections are appropriately referred to as computer-readable media. When software is transmitted from a web site, server, or other remote source, which uses wireless technologies such as, for example, coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or infrared, wireless, microwave, Wireless technologies such as cable, fiber optic cable, twisted pair, DSL, or infrared, radio, and microwave are included in the definition of media. As used herein, a disk and a disc include a compact disk (CD), a laser disk, an optical disk, a digital versatile disk (DVD), a floppy disk, and a Blu- ) Typically reproduce data magnetically, while discs reproduce optically 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 also 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 incorporated 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 or scope of the invention. Accordingly, 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, as well as the following claims.

Claims (75)

delete delete delete delete delete delete delete delete delete delete delete delete A system for distributing digital coupons via a mobile broadcast TV system,
Mobile Broadcast TV Network; And
A receiver device configured to receive a mobile broadcast TV transmission,
The mobile broadcast TV network,
A broadcast transmitter; And
Server,
The server may cause the server to:
Causing the broadcast transmitter to broadcast a coupon template containing coupon access information;
Receiving receiver device identity data from a receiver device;
Generating a digitally signed coupon comprising the digital signature, wherein the receiver device identity data and the coupon ID received from the receiver device are contained within a digest of the digital signature; And
Transmitting the digitally signed coupon containing the receiver device identity data and the coupon ID in the digest of the digital signature to the receiver device over a unicast network
Comprising server executable instructions configured to perform operations including:
The receiver device comprising:
A processor;
A memory coupled to the processor; And
And a receiver circuit coupled to the processor and configured to receive the mobile broadcast TV transmission,
The processor comprising:
Receiving the coupon template including the coupon access information;
Transmitting the receiver device identity data to the server based on the access information of the coupon template;
Receiving the digitally signed coupon from the server via the unicast network, wherein the digitally signed coupon comprises the receiver device identity data and the coupon ID in the digest of the digital signature;
Determining if the received receiver device identity data in the digest of the digital signature matches the transmitted receiver device identity data; And
Storing the digitally signed coupon in the memory when the received receiver device identity data in the digest of the digital signature matches the transmitted receiver device identity data
Wherein the system comprises processor-executable instructions for performing operations including: receiving a digital coupon from a mobile broadcast television system; 14. The method of claim 13,
Wherein the access information of the coupon template is selected from the group consisting of a URL and a telephone number. 14. The method of claim 13,
Wherein the receiver device identity data comprises one or more items selected from the group consisting of a receiver device MAC ID, a telephone number, a user account number, a group identifier, a personal identification number (PIN), and a user name, via a mobile broadcast TV system A system for distributing digital coupons. 14. The method of claim 13,
Wherein the processor is configured with processor executable instructions such that the receiver device identity data is transmitted to the server over the Internet. 14. The method of claim 13,
Wherein the processor is configured with processor executable instructions such that the receiver device identity data is transmitted to the server over the unicast network. delete 14. The method of claim 13,
Wherein the server is further configured to generate the digital signature using a chain of X.509 certificates that guide the creation of the digital signature of the digitally signed coupon to the root X.509 coupon- ≪ / RTI > wherein the mobile broadcast TV system is configured to broadcast digital coupons via a mobile broadcast TV system. 14. The method of claim 13,
Further comprising a point of sale (POS) system,
Wherein the processor is further configured to receive digital data via a mobile broadcast TV system, comprising processor executable instructions for performing operations that further comprise providing coupon data at the coupon redemption transaction and the digital signature at the receiver device to the POS system. A system for distributing coupons. 21. The method of claim 20,
Wherein the POS system is configured to verify the coupon data based on the coupon data and the digital signature. 21. The method of claim 20,
Receiving a coupon validation request from the POS system requesting confirmation of the validity of the digitally signed coupon, wherein the coupon validation request is accompanied by the digitally signed coupon, the receiver device identity data and the coupon ID Receiving the coupon confirmation request;
Decrypting the digital signature of the digitally signed coupon received by the coupon validation request;
Determining whether the receiver device identity and the coupon ID retrieved from the digital signature match the receiver device identity and the coupon ID; And
Transmitting to the POS system a coupon validation message identifying the digitally signed coupon if the receiver device identity searched from the digital signature and the coupon ID match the receiver device identity and coupon ID
Further comprising a coupon validation system configured with server executable instructions to perform operations comprising: receiving the coupon from the mobile broadcast TV system; 23. The method of claim 22,
The POS system is further configured to send a coupon cancellation message to the receiver device; And
Wherein the processor is further configured to perform the operations further comprising: in response to receiving the coupon cancellation message, deleting the digitally signed coupon from the memory of the receiver device. A system for distributing digital coupons through a TV system. 23. The method of claim 22,
The coupon validation system may further comprise means for decrypting the digital signature using a chain of X.509 certificates that directs the decryption of the digital signature to a root X.509 coupon- A system for distributing digital coupons via a mobile broadcast TV system.
delete delete delete delete delete delete delete delete delete delete delete delete A receiver device,
A processor;
A memory coupled to the processor; And
A receiver circuit coupled to the processor and configured to receive a mobile broadcast TV transmission,
The processor comprising:
Receiving a coupon template upon mobile broadcast TV transmission, the coupon template including coupon access information; receiving the coupon template;
Establishing a communication link with the server based on the coupon access information;
Transmitting receiver device identity data of the receiver device to the server;
Receiving a digitally signed coupon that includes the digital signature, wherein the digital signature includes the receiver device identity data and coupon ID sent from the receiver device in a digest of the digital signature;
Determining if the received receiver device identity data in the digest of the digital signature matches the transmitted receiver device identity data; And
Storing the digitally signed coupon in the memory of the receiver device when the received receiver device identity data in the digest of the digital signature matches the transmitted receiver device identity data
Comprising processor executable instructions for performing operations comprising: 39. The method of claim 37,
Wherein the access information of the coupon template is selected from the group consisting of a URL and a telephone number. 39. The method of claim 37,
Wherein the receiver device identity data comprises one or more items selected from the group consisting of a receiver device MAC ID, a telephone number, a user account number, a group identifier, a personal identification number (PIN), and a user name. 39. The method of claim 37,
Wherein the processor is configured with processor-executable instructions such that the communication link with the server and the receiver device identity data are transmitted to the server over the Internet. 39. The method of claim 37,
Wherein the processor is configured with processor-executable instructions such that the communication link with the server and the receiver device identity data are transmitted to the server via a unicast network. 39. The method of claim 37,
Wherein the processor is configured with processor executable instructions to perform operations further comprising identifying the digital signature,
And the digitally signed coupon is stored in the memory if the digital signature is verified. 43. The method of claim 42,
Wherein the processor is configured with processor executable instructions such that the digital signature is identified using a chain of X.509 certificates that directs to a root X.509 coupon-signing authority. 39. The method of claim 37,
Wherein the processor is further comprised of processor executable instructions for implementing coupon data during coupon redemption transactions and further comprising providing the digital signature to a point of sale (POS) system. 45. The method of claim 44,
The processor comprising:
Receiving a coupon cancellation message from the POS system; And
Deleting the digitally signed coupon from the memory in response to receiving the coupon cancellation message
Further comprising processor executable instructions for performing operations comprising: A receiver device,
Means for receiving a coupon template upon transmission of a mobile broadcast TV, the coupon template comprising coupon access information; means for receiving the coupon template;
Means for establishing a communication link with the server based on the coupon access information;
Means for sending receiver device identity data related to the receiver device to the server;
Means for receiving a digitally signed coupon comprising the digital signature, wherein the receiver device identity data and the coupon ID transmitted from the receiver device are contained within a digest of the digital signature; And
Means for determining if the received receiver device identity data in the digest of the digital signature matches the transmitted receiver device identity data;
And means for storing the digitally signed coupon in the receiver device if the received receiver device identity data in the digest of the digital signature matches the transmitted receiver device identity data. 47. The method of claim 46,
Wherein the access information of the coupon template is selected from the group consisting of a URL and a telephone number. 47. The method of claim 46,
Wherein the receiver device identity data comprises one or more items selected from the group consisting of a receiver device MAC ID, a telephone number, a user account number, a group identifier, a personal identification number (PIN), and a user name. 47. The method of claim 46,
Wherein the means for establishing the communication link with the server comprises means for establishing an internet communication link; And
Wherein the means for transmitting the receiver device identity data to the server comprises means for transmitting the receiver device identity data to the server over the established internet communication link. 47. The method of claim 46,
Wherein the means for establishing the communication link with the server comprises means for establishing a unicast communication link; And
Wherein the means for transmitting the receiver device identity data to the server comprises means for transmitting the receiver device identity data to the server over the established unicast communication link. 47. The method of claim 46,
Further comprising means for verifying the digital signature,
And the digitally signed coupon is stored in memory if the digital signature is verified. 52. The method of claim 51,
Wherein the means for verifying the digital signature comprises means for verifying the digital signature using a chain of X.509 certificates to guide the root X.509 coupon-signing authority. 47. The method of claim 46,
And means for providing coupon data and the digital signature to the POS system upon coupon redemption transaction. 54. The method of claim 53,
Means for receiving a coupon cancellation message from the POS system; And
And means for deleting the coupon from the memory in response to receiving the coupon cancellation message. A processor in a receiver device capable of receiving mobile broadcast TV transmissions,
Receiving a coupon template upon mobile broadcast TV transmission, the coupon template including coupon access information; receiving the coupon template;
Establishing a communication link with the server based on the coupon access information;
Transmitting receiver device identity data of the receiver device to the server;
Receiving the digitally signed coupon including the digital signature, wherein the receiver device identity data and the coupon ID transmitted from the receiver device are contained within a digest of the digital signature;
Determining if the received receiver device identity data in the digest of the digital signature matches the transmitted receiver device identity data; And
Storing the digitally signed coupon in the memory of the receiver device when the received receiver device identity data in the digest of the digital signature matches the transmitted receiver device identity data
The processor-executable instructions being configured to cause the processor to perform operations comprising: 56. The method of claim 55,
Wherein the access information of the coupon template is selected from the group consisting of a URL and a telephone number. 56. The method of claim 55,
Wherein the receiver device identity data comprises one or more items selected from the group consisting of a receiver device MAC ID, a telephone number, a user account number, a group identifier, a personal identification number (PIN), and a user name. 56. The method of claim 55,
Establishing the communication link with the server comprises establishing an Internet communication link; And
Wherein transmitting the receiver device identity data to the server comprises transmitting the receiver device identity data to the server via the established internet communication link. 56. The method of claim 55,
Establishing the communication link with the server comprises establishing a unicast communication link; And
Wherein transmitting the receiver device identity data to the server comprises transmitting the receiver device identity data to the server via the established unicast communication link. 56. The method of claim 55,
Wherein the stored processor executable instructions are configured to cause the processor to perform operations further comprising identifying the digital signature,
And if the digital signature is verified, storing the digitally signed coupon in the memory is accomplished. 64. The method of claim 60,
Wherein verifying the digital signature comprises verifying the digital signature using a chain of X.509 certificates to guide the root X.509 coupon-signing authority. 56. The method of claim 55,
Further comprising providing coupon data and the digital signature to the POS system upon coupon redemption transaction. 63. The method of claim 62,
The stored processor executable instructions cause the processor to:
Receiving a coupon cancellation message from the POS system; And
Deleting the digitally signed coupon from the memory in response to receiving the coupon cancellation message
And to perform operations that further comprise the steps of: A method of providing a digital coupon to a receiver device via a mobile broadcast TV system,
Broadcasting a digitally signed coupon from a mobile broadcast TV network, wherein the digitally signed coupon includes a digital signature, and receiver device identity data and coupon ID received from the receiver device are stored in the digital signature Said broadcasting being included in a digest of;
Receiving the digitally signed coupon at the receiver device;
Decrypting the digital signature using a decryption key;
Obtaining receiver device identity data included in the digital signature;
Determining whether the acquired receiver device identity data matches the identity data of the receiver device; And
And storing the digitally signed coupon in a memory of the receiver device if there is a match between the acquired receiver device identity data and the identity data of the receiver device. 65. The method of claim 64,
Wherein decrypting the digital signature is accomplished using a chain of X.509 certificates to guide the root X.509 coupon-signing authority. A receiver device,
A processor;
A memory coupled to the processor; And
A receiver circuit coupled to the processor and configured to receive a mobile broadcast TV transmission,
The processor comprising:
Receiving a digitally signed coupon from a mobile broadcast TV network, wherein the digitally signed coupon includes a digital signature, and wherein the receiver device identity data and coupon ID of the receiver device are included within a digest of the digital signature Received, received;
Decrypting the digital signature using a decryption key;
Obtaining the receiver device identity data included in the digital signature;
Determining whether the acquired receiver device identity data matches the identity data of the receiver device; And
Storing the digitally signed coupon in the memory when there is a match between the obtained receiver device identity data and the identity data of the receiver device
Comprising processor executable instructions for performing operations comprising: 67. The method of claim 66,
Wherein the processor is configured with processor executable instructions such that decryption of the digital signature is achieved using a chain of X.509 certificates that directs the root X.509 coupon-signing authority. A receiver device,
Means for receiving a digitally signed coupon from a mobile broadcast TV network, wherein the digitally signed coupon comprises a digital signature and wherein the receiver device identity data and coupon ID of the receiver device are within a digest of the digital signature The receiving means included;
Means for decrypting the digital signature using a decryption key;
Means for obtaining receiver device identity data included in the digital signature;
Means for determining whether the acquired receiver device identity data matches the identity data of the receiver device; And
And means for storing the digitally signed coupon if there is a match between the obtained receiver device identity data and the identity data of the receiver device. 69. The method of claim 68,
Wherein the means for decrypting the digital signature using the decryption key comprises means for decrypting the digital signature using a chain of X.509 certificates to guide the root X.509 coupon- . A processor of a receiver device capable of receiving mobile broadcast TV transmissions,
Receiving a digitally signed coupon from a mobile broadcast TV network, wherein the digitally signed coupon comprises a digital signature;
Decrypting the digital signature using a decryption key;
Obtaining the receiver device identity data included in the digital signature;
Determining whether the acquired receiver device identity data matches the identity data of the receiver device; And
Storing the digitally signed coupon when there is a match between the obtained receiver device identity data and the identity data of the receiver device
The processor-executable instructions being configured to cause the processor to perform operations comprising: 71. The method of claim 70,
Decrypting the digital signature using the decryption key comprises decrypting the digital signature using a chain of X.509 certificates to guide the root X.509 coupon-signing authority. Storage medium. delete delete delete delete

Images