JP2012511283A - System and method for distributing and redeeming credit over a broadcast system - Google Patents

Abstract

The method and system allows a receiver device to receive an electronic coupon from a mobile TV broadcast service provider. Coupon templates can be broadcast to mobile devices. To receive a digitally signed coupon, a coupon template can be used to communicate with the coupon manager. The coupon manager can use the received data to create a digitally signed coupon for delivery to the receiver device over the unicast network. Digitally signed coupons can also be broadcast to the receiver device. The receiver device can verify the received electronic coupons using the digital signature to identify coupons intended for them. Electronic coupons can be redeemed at point of sale. Merchant can use their digital signature to verify the coupon locally. To allow the recipient to verify that the coupon originated from a trusted entity, route X. X. 509 A coupon digital signature can be generated using a chain of 509 certificates.

Description

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

  This application also separately claims the benefit of priority of US Patent Application No. 61 / 120,355 entitled “Enhanced Coupons for Broadcast Content Redemption” filed on Dec. 5, 2008.

  Wireless communication technology has experienced explosive growth over the past few years. This growth has been accelerated by a wireless service that gives the mobile public freedom of movement and breaks the constraints on wired communication systems. In addition, improvements in the quality and speed of voice and data communications over wireless media have attracted additional users. As a result of these service extensions, the popularity of wireless services is expected to continue to grow rapidly.

  A recent addition to wireless communication technology is the ability to broadcast television to mobile users. Mobile broadcast users can use their cell phones or other wireless devices to view mobile versions of news, entertainment, sports, business, and other programs. These broadcast systems are experiencing significant increases in usage and availability around the world. Currently, users of mobile television and broadcast systems pay a fee to receive program content. These charges vary depending on the service provider and the selected service level.

  Various embodiments herein provide digitally signed coupons to receiver device users and purchase rights to view broadcast content or purchase products or services. A method and system for redeeming the coupons of the present invention. In one embodiment, encrypted coupon templates can be delivered to receiver device users via a broadcast network. The receiver device can decrypt the coupon template and use the data obtained from the coupon template to request a coupon with a digital signature from the coupon manager. The coupon manager can receive a request for a digitally signed coupon along with device data. The coupon manager can use the device data to create a digitally signed coupon and distribute it to the requesting receiver device over a unicast network or the Internet. To prevent counterfeit coupons or other spoofing to legitimate coupon holders, a signature for the coupon can be calculated across the coupon record including coupon identification information.

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

  In a further embodiment, the digitally signed coupon can be redeemed at a point of sale. Presenting the coupon at a point of sale allows the point of sale system to verify the coupon based on the coupon data and the digital signature. Alternatively, the coupon itself can indicate that the merchant point of sale system should request the coupon manager to validate the coupon by sending the coupon and receiver device data to the coupon manager. . The coupon manager can decrypt the coupon signature and determine whether the coupon and the received data match the data retrieved from the coupon signature. If the data matches, the coupon manager can send a validation message to the point of sale to authorize or authenticate a purchase transaction using the presented coupon. A cancel message can also be sent to the receiver device to delete or cancel the coupon presented from the receiver device. If the data does not match, the coupon manager can send a rejection message to the point of sale to notify the merchant that the coupon is not authentic or not authenticated for the purchase transaction. .

  In a further embodiment, the digitally signed coupon can include a weighted number. A coupon manager can use such weight numbers to determine whether two or more coupons can be combined in a single purchase transaction. The coupon manager can receive coupon data from the point of sale and calculate the total number of weights. If the sum of the weight numbers of several coupons is greater than a predetermined number, the coupon combination can 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 above and the detailed description below, illustrate the present invention. It serves to explain the features of the invention.
4 is a process flowchart of a conventional method used to provision a receiver device to receive a mobile broadcast. 6 is a process flow diagram of an overview process for providing coupons to a receiver device, according to various embodiments. FIG. 2 is a network component diagram showing various components of a mobile broadcast TV system. 4 is a process flow diagram of one implementation method for delivering credits or coupons to a receiver device. 4 is a message flowchart of one implementation method for delivering credits or coupons to a receiver device. The message structure figure of one Embodiment of a subscription response message. FIG. 4 is a message structure diagram of one embodiment of a bonus credit element. The message structure figure of other embodiments of a coupon element. FIG. 4 illustrates pointer references between coupon documents and service guide fragments, according to one embodiment. FIG. 4 is a message structure diagram of one embodiment of a bonus credit element. A list of possible error codes to use in one embodiment. 4 is a process flow diagram of one implementation method for delivering credits or coupons to a receiver device. 4 is a process flowchart of another implementation method for delivering credits or coupons to a receiver device. FIG. 10B is a message flowchart of the implementation method shown in FIG. 10A for delivering credits or coupons to a receiver device. 10B is a message flowchart of the implementation method shown in FIG. 10B for delivering credits or coupons to a receiver device. Fig. 3 is a message structure of one embodiment of a token purchase response. 4 is a process flowchart of another implementation method for delivering credits or coupons to a receiver device. The message flowchart of embodiment shown in FIG. 4 is a process flowchart of one implementation method for redeeming a credit or coupon. The message flowchart of embodiment shown in FIG. 4 is a process flowchart of another implementation method for redeeming credits or coupons. The message flowchart of embodiment shown in FIG. 4 is a process flowchart of another implementation method for redeeming credits or coupons. The message flowchart of embodiment shown in FIG. 4 is a process flow diagram of one implementation method for managing expired credits or coupons. 4 is a process flow diagram of one implementation method for managing credits or coupons used. 4 is a process flow diagram of one implementation method for broadcasting an encrypted coupon template and retrieving a digitally signed coupon. 4 is a process flowchart of one implementation method for broadcasting a digitally signed coupon. 4 is a process flow diagram of one implementation method for redeeming a digitally signed coupon. 4 is a process flow diagram of one implementation method for managing a digitally signed coupon that is used. 4 is a process flow diagram of one implementation method for permitting the combination of two coupons for a purchase transaction. FIG. 2 is a component block diagram of a receiver device suitable for use in one embodiment. FIG. 2 is a component block diagram of a server device suitable for use in one embodiment.

Detailed description

  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 particular examples and implementations are for illustrative purposes, and are not intended to limit the scope of the invention or the claims.

  The word “exemplary” is used herein to mean “serving as an example, instance, or illustration”. Any embodiment described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other implementations.

  As used herein, the terms “receiver device” and “mobile device” are used herein to refer to cellular phones, personal digital assistants (PDAs), palmtop computers, Wireless e-mail receivers (eg, BlackBerry® and Treo® devices), multimedia Internet-enabled cellular phones (eg, BlackBerry Storm®), and Global Positioning System (Global Positioning System) GPS) receiver, wireless game controller, and similar personal electronic device including a programmable processor, memory and receiver circuitry for receiving and processing mobile broadcast television services. Used interchangeably or to refer one or all Re. Although a mobile device as used herein is a receiver device, not all receiver devices are “mobile” because some embodiments can be implemented with non-mobile receiver devices.

  The words “credit”, “incentive”, “promotion”, “coupon” and “token” are used herein to mean one or more mobiles, for example. Used interchangeably to refer to a unit of value that can be exchanged for or spent on something of value, such as the ability to receive a television broadcast or purchase a product or service To do. In the context of various embodiments, a vendor, company, or content provider may reward consumers for purchasing various products or services or viewing certain content. Or program such credits or coupons to motivate consumers to take a particular course of action, watch a particular program, or purchase a particular product or service Can be issued or created as part of

  The term “unicast network” is used herein to refer to a communication network that transmits data to a single 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 email messages carried over a cellular telephone data communication network.

  The word “broadcast” is used herein to mean the transmission of data (information packets) such that the data can be received by multiple receiving devices. An example of a broadcast message is a mobile television service broadcast signal.

  The word “content provider” is used herein to refer to a company that provides video, websites, and other data that is broadcast over mobile television systems. The term “network provider” is used herein to refer to an entity that broadcasts a mobile television signal. In general, a network provider receives broadcast content from a content provider. The term “advertisers” is used herein to refer to merchants, manufacturers, service providers, and product placement within advertising or paid for broadcast content ( Used to refer generally to other entities that may purchase product placements).

Reference Table 1 below includes an alphabetical list of abbreviations used herein, along with their associated meanings.

  The expansion of mobile television (TV) popularity has led to new revenue for content providers, network providers, and other advertisers who can use new media to reach merchants, manufacturers, service providers, and consumers. Provided sources of revenue. New revenue models include subscription-based sales of mobile television access, PPV or PPT mobile television access, advertising, and products and services to consumers such as through loyalty or incentive programs Including cross marketing. For example, mobile TV network providers can generate revenue from their services by selling subscriptions to users with access to a mobile TV broadcast network limited to subscribers. Merchants or manufacturers can advertise on mobile TV broadcast systems to generate revenue from the sale of their products and services. As usage continues to increase, mobile broadcast service providers, for example, are distributed to mobile receiver devices and coupons that can be exchanged to purchase mobile TV content (ie, viewing privileges), services or products, and It may be desirable to simplify and facilitate access to consumers by using credits, such as tokens.

  Mobile TV users use home television viewing devices (i.e. receiver devices) that can receive mobile TV broadcast services and communicate via unicast messages. Different from viewers. Further, in many cases, only one person uses the mobile device, so the mobile receiver device can be personalized to the user. In general, users carry their mobile devices everywhere, including when shopping for products and services. Thus, mobility and access to mobile TV broadcast services means that mobile receiver devices can be very valuable marketing tools to reach specific customers and build customer loyalty. . Thus, mobile receiver devices offer a unique opportunity to reward high-value customers.

  Providers can employ various methods to measure the value of their customers. For example, users who are heavily using their receiver device to view mobile broadcast TV content may be particularly beneficial to content providers such as television producers, movie studios, and music publishers. Using technology available on the mobile device, the user can either explicitly, for example, by voting in a program, voting (betting), or by purchasing a utility, or implicitly by, for example, audience measurement The actual content to be viewed can be measured. In addition, the measurement software can operate in conjunction with a tuner on the mobile device to monitor channel changes to make an accurate measurement of the broadcast viewer. In addition, mobile device unicast communication capabilities can be used to receive immediate feedback and direct measurements of content viewing. In addition to being able to determine who is viewing the content provider's content, the mobile device also gives the content provider important demographic information so that the content provider It may be possible to characterize those viewers with respect to the audience segment and related consumer information.

  In addition to being able to measure general audience participation and demographics, pay-per-view and pay-per-time access services enable content providers to Can be identified and tracked. Thus, targeted consumer loyalty programs can be made available on mobile devices in ways not possible with conventional broadcast television.

  Content providers can identify individual viewers and may wish to implement targeted marketing programs aimed at retaining their customers, increasing customer satisfaction and promoting similar content . One vehicle for building customer loyalty and expanding viewers involves rewarding customers with free access to broadcast content. For example, a content provider may want to grant a royal viewer a credit or coupon that allows them to watch a first-run movie or access a free music download. Thus, a content provider may wish to give a coupon to encourage viewers of a particular mobile TV program to watch a similar movie in a traditional cinema. Similarly, content providers may want to give royal viewers credits or coupons that allow their programs to be viewed more on mobile TV. In addition, content providers can perform cross-promotion to provide home (possibly fixed) subscription-based televisions such as, for example, DirecTV (TM) or Dish (TM) Network. You may want to invite viewers to view content on the John System.

  Not only content providers benefit from customer loyalty coupons that can be delivered to mobile devices. Commercial businesses that sell directly to consumers, such as retail stores and consumer service providers, for example, can identify their customers at a point of sale (POS). Traditionally, merchants have provided customers with paper coupons and similar promotional items. The technical capabilities of mobile devices give merchants new vehicles to reward customer loyalty. For example, a merchant may wish to give a royal customer a credit or coupon that can be used to view a mobile TV program. If a credit or coupon allows a customer to view a program that includes an advertisement from a merchant that gives the credit or coupon, such merchant can benefit from a dual advertising profit.

  In addition, mobile TV broadcast service providers may also want to give their customers credits or coupons that allow them to watch additional content or purchase products or services at a discounted rate.

  Other reasons enterprises, content providers, and mobile broadcast network providers give credits or coupons to customers are to recognize previous services or attract future interactions and to unicast network traffic generated by service interaction activities. Including rewarding, compensating for or viewing future advertisements, and giving premium customers a bonus. Credits or coupons can also be given as part of a customer loyalty program (eg, air mileage, hotel points, dining dollars, etc.). Further, if consumer demographics can be accurately determined, credits or coupons are given to accurately cross sell products or services that such consumers may desire be able to.

  A number of different mobile broadcast television services and broadcast standards, all of which implement various embodiments and can benefit from, are available or contemplated in the future. Such services and standards include the Open Mobile Alliance Mobile Broadcast Services Enabler Suite (OMA BCAST), MediaFLO, and digital video broadcast IP datacasting. (Digital Video Broadcast IP Datacasting) (DVB-IPDC) and China Multimedia Mobile Broadcasting (CMMB). In general, mobile broadcast transmissions are encrypted so that access to the program can be sold on a subscription or pay-per-view basis. Various mechanisms can be used to link the decryption key to the subscription purchase. In general, a mobile broadcast service is a unicast communication network, such as a customer's cellular telephone data service, for communicating subscription messages with a particular customer mobile device, and a mobile television program on all mobile devices. And a separate broadcast network for broadcasting. In general, a mobile broadcast service provider can send a message that includes information that enables the mobile device to generate the decryption key needed to receive a particular broadcast. Expire the decryption key after a certain amount of time to enable pay-per-view services and to limit the economic impact of being free to use the decryption key Can be configured. Further, the message providing the decryption key can include service limiting parameters that can be used to limit the received broadcast service to a particular program, channel, or other market segmentation.

  As an example, the OMA BCAST standard provides a limited access key using a long-term key message (LTKM) sent to a mobile device over a unicast network. The mobile device uses its limited access key to generate a traffic encryption key (TEK) contained in encrypted form in a short-term key message (STKM) that is periodically broadcast over the broadcast network. Decrypt. Once decrypted, the TEK allows the mobile device to decrypt the encrypted broadcast content stream for a short period of time (eg, 2 minutes). When the TEK expires, if no new TEK is obtained, access to the encrypted broadcast content is terminated. In order to allow customers to watch the entire program, STKM messages are broadcast continuously so that they can get new TEKs from those STKMs using the long-term key obtained from LTKMs. The

  Various embodiments are described below using OMA BCAST standard terms and message names as illustrative examples. Other mobile broadcast standards use similar messaging structures that differ in message names and details that are not important to various embodiments. For example, DVB-IPDC uses a key management message (KMM) in a manner similar to LTKM in the OMA BCAST standard, uses a key stream message (KSM) in a manner similar to STKM in the OMA BCAST standard, and uses the OMA BCAST standard. The TEK is used in the same manner as the TEK. Similarly, MediaFLO and CMMB use the encryption management message (EMM) in the same way as the OMA BCAST standard LTKM and the encryption codeword message (ECM) in the same way as the OMA BCAST standard STKM. A code word (CW) is used in the same manner as TEK of the OMA BCAST standard. Accordingly, the following description is provided as an illustrative example and does not limit the scope of the embodiments or the claims to the OMA BCAST standard. For ease of reference, a longer-term rights management message is referred to herein as a long-term decryption key message or LTKM, and a shorter-term decryption key delivery message is referred to herein as a short-term decryption key message or STKM. The decryption key used to decrypt the encrypted broadcast content will be referred to herein as the content decryption key or TEK.

  Currently, mobile broadcast TV systems allow consumption of services or content by purchasing subscription tokens or credits. In other words, the user must first pay for becoming a subscriber or prepay for a token that can later be redeemed for program content. For example, in a typical mobile broadcast TV system, customers can purchase one token for every dollar they pay. The electronic wallet is then activated in the mobile device and the token is deducted when the user watches the mobile TV program. Once the user has consumed all of his tokens, he must purchase a new token before he can watch additional mobile TV programs.

  FIG. 1 is a process flow diagram illustrating a current regime in which a mobile device user can subscribe to or purchase a mobile TV broadcast service. In creating a broadcast service or content, the mobile TV service provider has created and agreed on a set of usage charging rules (step 100). Based on these charging rules, the service provider creates a subscriber management key (SMK) and establishes service registration (step 102). The service provider receives a request for service subscription from the user (step 104), or receives a request from the user to purchase a prepay per-view or pay-per-time token (step 108). The mobile broadcast service provider sells the requested subscription or token to the requesting user (steps 106, 110), after which the mobile broadcast service provider sends an LTKM message over the unicast network to the user's mobile device. (Step 112). The LTKM includes a long term key for decrypting messages sent over the broadcast network. Long-term keys generally depend on subscriptions or services. For example, a user can subscribe to a basic level membership that would allow, for example, to receive only basic cable broadcast channels on the user's mobile device. At this level of membership, the user may not be able to watch premium channels such as HBO® or ShowTime®. In general, the use of different long-term keys between the basic channel and the premium channel allows channel access control.

The LTKM can also include service rules that control the use of the long-term keys described above. Such rules define usage criteria and constraints, and their instantiation is generally in the terms and conditions of the contract. Dependent. For example, the service rules may allow modes of content consumption, ie, existing subscriptions to live services, PPV access to live events, PPV access to either live events or recorded content, or One of the unlimited playbacks of the recorded content can be notified to the device. The LTKM is sent in a message intended for a specific user's mobile device via a unicast network, and the long-term key is stored in a secure function, for example, a secure memory of the terminal or a smart card. The service provider then broadcasts the STKM (step 114). The service provider also sends the encrypted program content stream continuously over time (step 115). STKM allows encrypted program content to be viewed on a mobile device. Every mobile device in the service provider network receives a broadcast of the STKM stream and the associated encrypted content stream. However, not every user can decrypt every STKM needed to decrypt the content. A user's viewing privileges are based on service rules defined in LTKM for each mobile device. Thus, if the service rules provided in LTKM allow viewing of program content, the mobile device decrypts one or more TEKs, decrypts the content, and displays it on the mobile device display. (Step 116). If the token is purchased and the LTKM rules allow viewing of the program content, the token is first deducted from the mobile device electronic wallet (eg, smart card), then the TEK is decrypted, and then the content using the TEK Is decrypted. However, if the service rule given in LTKM does not allow access to the program content, the terminal may decrypt the encrypted TEK in the STKM stream to allow viewing of the program related to the STKM stream. It will not be possible.

  However, current systems are limited in their ability to issue credits to users for promotion or create purchase incentives in the form of coupons or free tokens. Currently, the only way for mobile broadcast TV systems to give credit to users is to distribute coupons to mobile broadcast TV users when the service is purchased. These coupons are sent to the user as part of the purchase data that is sent to the user's mobile device along with the content. Since these coupons are distributed when a user purchases a service, they do not target a specific user or user group. The token is also sold to the user by the service provider. However, these tokens are only given at the time of purchase requests, and current mobile broadcast TV systems do not have a means of decoupling token granting from the intended purchase. In other words, current mobile broadcast TV systems do not have the ability to issue free or discount tokens, so tokens must be requested. Further, the mobile broadcast TV network is not configured to deliver a different amount of tokens than the requested amount. Thus, even if the content provider or network service provider wishes to give more royal tokens to the royal customer than purchased tokens, the system will not allow this to be done. These current limitations include mobile broadcast service providers, network providers, etc., whose customers, for example, use their services, populate their unicast networks or watch their advertisements. Or prevent creating incentives to shop at those stores.

  In order to overcome these limitations and enable new marketing use of mobile TV broadcast services, various implementation methods and systems have been made available by making free or discounted goods or services available to their customers. Allows credits that can be used in new revenue models and customer recognition reward programs to be delivered to mobile devices. Content providers, mobile broadcast service providers, and advertisers can issue targeted credits (eg, coupons and tokens) to mobile device users. These credits are then used for free or discount viewing of additional mobile TV content or purchase of products or services, thus creating an incentive for users to continue or increase the use of mobile broadcast TV systems. be able to.

  Within various embodiments, a user can be credited for a variety of reasons. For example, free service trials, content sampling, loyalty awards, early bird awards, new subscriber service discounts, and royal subscribers Credits can be given to users for loyal subscriber content discounts. Credits can be issued with various types of restrictions that can be specified by the credit originator. Universal credits can be used to purchase all kinds of services and products from anywhere. For example, universal credits can be used to make purchases at POS, for online shopping, or to purchase mobile broadcast TV services. Credits can also be limited to program credits that can only be used to purchase programs from mobile broadcast TV systems. The credit may further be a specific credit that can only be used to purchase a specific service or product, for example, a product from an originated merchant or manufacturer.

  In various embodiments, like a type of currency, credits can be given in the form of tokens or coupons that can be used to purchase free or discount services, programs or products. For example, a user can use a token to purchase a pay-per-view (PPV) mobile TV program on the user's mobile device. To create incentives for users to purchase products and services, tokens can be given to users for free or at a discount as credits or promotions. There are two types of tokens for metered consumption of broadcast services, as defined in OMA BCAST 1.0. The “user” token can be used to consume any content item under the user membership or subscription level defined in the service guide rules. “Service” tokens are limited to programs available under a unique service in the user's membership or subscription. It should be noted that in some mobile broadcast TV systems, such as BCAST, there may be no distinction between membership and subscription in terms of service guide and program viewing. However, a flexible exchange of tokens or coupons for obtaining goods, services, and / or programs can be more accurately addressed with respect to membership that can relate to individual privileges.

  In various embodiments, coupons delivered to mobile devices can serve as a type of currency that can be exchanged for financial discounts or rebates when purchasing products and services. Unlike paper coupons, which are often widely distributed by email, magazines, newspapers, etc., coupons enabled in various embodiments can be distributed to mobile devices via a mobile TV broadcast service. Once delivered to the mobile device, the user can use such coupons to obtain discounts and promotional items in the same way as redeeming paper coupons.

  Different implementation methods and systems can allow different advertisers to configure credits for different purposes. Credits can be limited with respect to their use. For example, credits can be configured to be valid for a particular time window, apply to any purchased item quantity, and are independent of the actual price of the item. Credits can be exclusive (eg, coupons that cannot be combined) or non-exclusive (eg, coupons that can be combined if the coupon providers are different). Credits can also be applied to many different purchased items (ie individual products or services). Credits are also purchased for products and services characterized by a single set of purchase data (eg, one-time program viewing, product, or single service), such as those that apply to subscription or continuous service purchases. It can also be applied to purchases characterized by multiple sets of data. In order to support the purchase of multiple data packages such as subscriptions, credits can be configured to apply to a subset of purchase data. Credits can be configured for just one user or group of users, such as royal or new users, who do not have the right to transfer, or can be transferred from the owner to another recipient. Can be configured to be.

  FIG. 2 is a process flowchart of the overall process for creating credits, delivering credits to users, and consuming credits on mobile devices. When a user uses the user's mobile device to view mobile broadcast TV content (step 200), the mobile TV service provider can measure the user's usage (eg, usage level and type). Such tracking, based on measuring both the amount and selectivity of broadcast content viewed on a user's mobile device, may be beneficial not only for content providers but also for service providers. Mobile TV service providers benefit from frequent usage / consumption paid by subscription fees or one-time token purchases, which directly generates mobile broadcast service provider revenue. Similarly, content providers benefit from increased demand for their content, which leads to increased advertising revenue and fees paid by mobile broadcast network providers. Also, the more users use the unicast function of a user's mobile device to participate in a program, such as voting for a user's favorite singer in a TV singer contest program, the more unicast service Cellular network providers that give you more revenue. Service providers, content providers and advertisers can then analyze each user's viewing habits to target highly-valuable users and provide users with promotional and incentive credits or coupons. Send. Accordingly, any one or more of a mobile broadcast service provider, a unicast network provider, a content provider, and an advertiser company creates a target credit or coupon for distribution to a particular user or group of users ( Step 202). Such credits can include coupons or free tokens to be used when purchasing services or products. Once a valuable user or user group is identified and matched to the appropriate credit type, the credit is sent to the identified user's mobile device (step 204). As will be described in more detail below, such credits can be delivered by unicast or broadcast transmission methods. Upon receiving such credits, the mobile device stores them in secure hardware that may be a secure memory on the terminal or compatible with a removable smart card for use in a mobile broadcast TV system. . The user then redeems the credit by purchasing a product or service using the user's mobile device (step 206). For example, a royal user mobile broadcasts credits that should be used to purchase free cleaning products from a merchant or manufacturer while watching product ads while watching a series of drama programs on their mobile device Can be received from a service provider. Upon receipt of the credit, the user can purchase the product online, such as by clicking on a hyperlink URL to access the merchant or manufacturer's web store, provided with the credit. Alternatively, when a user visits a store, the user presents the mobile device at a point of sale and transfers other credits or electronically records the use of the credits for other downloadable e-coupons. So that coupons can be used.

  FIG. 3 is a network component diagram of a mobile broadcast TV system showing participants involved in delivering credit to mobile devices. In mobile broadcast TV systems, credits can be created by various companies, including broadcast service provider 30, third party company 50, and content provider 60. The broadcast service provider 30 is a company that provides business relationships with end users, typically subscription-based. 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 the mobile device 40. The broadcast network 80 is a dedicated downlink-only broadcast transmission system such as FLO® or a cellular based broadcast / multicast system such as a system defined by 3GPP MBMS or 3GPP2 BCMCS, for example. It can be. 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 provider 60. These contents are then transmitted to the broadcast network operator, which broadcasts the content via their mobile broadcast TV network 80 or unicast network 70. In some cases, broadcast service provider 30 may also be a cellular service provider, in which case cellular service provider 30 also provides and operates a unicast network 70 that provides voice and data services to mobile devices 40. However, the broadcast service provider 30 need not be a unicast (eg, cellular) network 70 provider. Even if the unicast network 70 and the broadcast network 80 are operated by different entities, the mobile broadcast service provider 30 still sends messages to and from the mobile device 40 via a unicast network operated by another company. And can be received.

  Third parties 50 may include merchants and manufacturers, such as HomeDepot®, Starbucks®, and Netflix®, who may wish to target mobile device users for promotion. The third party 50 can interact directly with the user, for example when the user visits their stores, or the user via the broadcast service provider 30, for example by showing an advertisement in a mobile broadcast TV program. You can interact with.

  Content providers 60 may include companies that provide content and programs for broadcast over the mobile broadcast TV network 80. Content providers can also include advertising agencies, government agencies, and private individuals who create audio, video and image content for broadcast. For example, the content provider may be National Broadcasting Corporation (NBC) that provides news and entertainment content for broadcast over the mobile broadcast TV network 80. Advertising agency content provider 60 may contract with third party 50 to create advertising content for those products and services. For example, Netflix (R) may sign a contract with an advertising company to produce advertisements for Netflix (R) services.

  In addition to the unicast network 70 and the mobile TV broadcast network 80, the user may communicate with the broadcast service provider 30 and the content provider 60 via other communication links such as a telephone (not shown) and the Internet 90, for example. it can. For example, the user can connect to the mobile broadcast service provider 30 and the content provider 60 via the user's mobile device 40 (eg, via a cellular data network not shown separately) or via a computer coupled to the Internet. You can access the website maintained by Similarly, a user can communicate directly with the third party 50 by connecting to a website of the third party 50 via the Internet or by walking into a store of the third party 50.

  Various implementation methods and systems can be used directly over many transport networks, such as, for example, SMS messages over the broadcast network 80, the Internet 90, the unicast network 70, and directly at the point of sale of purchase transactions. Allow credit distribution and redemption. Based on the use of the user's mobile device 40 for a mobile broadcast TV system, the user's mobile device 40 can be targeted for credit delivery. Credits can be delivered directly or indirectly to the user's mobile device 40. For example, when a user makes a purchase on a corporate website via the Internet 90 using the user's mobile device 40, credits can be delivered directly to the mobile device 40. Such credits can also be used as part of an internet session established in such online purchases or out-of-band means (out, for example, by SMS, MMS or email messages delivered via unicast network 70). -of-band means) to the mobile device 40. For example, the user's mobile device 40 may receive a free cup of coffee credits that may be sent from Starbucks® via an out-of-band method, such as by SMS, MMS or email. Regardless of the method of credit distribution, the user's mobile device 40 may be able to redeem credits via the broadcast service provider 30, for example, to receive free or discounted mobile TV programs.

  Deliver credits indirectly to target users, such as when a third party 50 submits credits to an intermediary (eg, mobile broadcast service provider 30) for delivery to the user's mobile device 40. You can also Distribution of credits to the mobile device 40 by the broadcast service provider 30 can be accomplished using various methods. One method provides credit to the user's mobile device 40 when the user communicates with the service provider 30 to purchase a viewing token or subscribe to a broadcast service. Distribution of such credits can be achieved by a service subscription response message sent by the broadcast service provider 30 in response to a subscription request message of the mobile device 40. For example, when the mobile device 40 sends a subscription request message to the service provider 30, eg, to request a service subscription extension or upgrade (eg, from basic to premium), the service provider 30 Can deliver the third party 50 coupon to the user's mobile device 40 as part of the subscription response message. Distribution of such credits can be via the unicast network 70 and can be based on the user's perceived value to the credit issuer, or user habits. The second method may include delivering such credits to the user's mobile device 40 when communication is not initiated by the user's mobile device 40. In this manner, the service provider 30 can send (ie, push) credits to the user's mobile device 40 via a dedicated service provisioning message.

  In order to support the distribution, processing and redemption of mobile TV system credits and coupons, various contractual and technical aspects can be matched, followed by targeted distribution of credits to users. The contractual aspects include defining message interface specifications between the third party 50 and the mobile broadcast service provider 30 and establishing business rules relating to consumption and billing semantics for credits and coupons. Can be included. For example, coupon type A can be redeemed for X minutes for viewing a purchased mobile TV program, and coupon A can be defined as expires on date Y. Other examples may include a free token that the user can redeem for a nominally defined program viewing price $ Z transferred from the third party 50 bank to the service provider 30 bank as part of the transaction.

  The technical aspects required to support mobile TV system credits and coupons can include using service provisioning messages to enable credit granting and redemption. In addition to communicating information between the mobile broadcast service provider 30 and the mobile device 40, the service provisioning message can cause the receiving mobile device 40 to be prepared to accept credit. Accordingly, the mobile broadcast service provider 30 can create a specific target service provisioning message for credit delivery, for example, to target a royal user's mobile device for such message. When the mobile device is prepared to receive credit, the mobile broadcast service provider 30 sends the credit (ie, LTKM) with its associated rules to the target mobile device 40, such as via the unicast network 70, for example. can do.

  FIG. 4 illustrates an implementation method for delivering credit from mobile broadcast service provider 30 to mobile device 40 using a subscription response message. FIG. 5 is a message flowchart illustrating the exchange of messages that may occur between various mobile broadcast TV system components to deliver credits in the implementation method shown in FIG. This implementation method will be described below with reference to both FIG. 4 and FIG.

  In the illustrated embodiment, the mobile broadcast TV service provider 30 sends a report to the third party 50 stating that program content will be broadcast soon (step 302 in FIG. 4 corresponding to message 500 in FIG. 5). This advance notification of broadcasted programs allows third parties 50 to evaluate programs for placement of advertisements and to conduct promotional campaigns, such as giving credit or coupons to target consumers, for example. Become. Upon receiving the broadcast program report (step 502), the third party 50 can determine whether it wants to give credit to the user's mobile device 40, such as in the form of a coupon or token. To give credit to the consumer, the third party 50 sends a credit request message to the service provider 30 (step 504 in FIG. 4 corresponding to message 502 in FIG. 5). This credit request message may be, for example, the value of the credit to be delivered, their applicability (eg, redeemable program, product or service), their expiration date, and their redemption rules The details of the credit to be delivered can be identified. Upon receiving such a credit request message (step 304), service provider 30 sends a credit response to third party 50 (step 306 in FIG. 4 corresponding to message 504 in FIG. 5). The third party 50 receives a credit response that can verify that the service provider 30 has received and processed the request of the third party 50 and communicate data relating to the terms and conditions agreed in advance for consumption and payment ( Step 506). In preparation for delivering the third party 50 credit to the mobile device 40, the service provider 30 creates a subscription response message that includes the credit details provided by the third party 50 (step 308). The structure, elements and parameters of the subscription response message will be described in more detail below with reference to FIGS. Sometime later, the user mobile device 40 may request or initiate a service adjustment, such as purchasing a viewing token, purchasing a pay-per-view token, a subscription request, or an upgraded service, for example. A service request is sent over the unicast network to the mobile broadcast service provider 30 (step 402 in FIG. 4 corresponding to message 506 in FIG. 5). The mobile broadcast service provider 30 receives and processes the service request (step 310), and accordingly sends an appropriate service provisioning response message to the mobile device 40 using the unicast or broadcast network 70 (FIG. 5). Step 312 in FIG. 4 corresponding to middle message 600). This service response may include third party credits as well as service adjustments requested by the user. The user's mobile device 40 receives the subscription response message via the unicast network 70, accesses the message content, and stores the credit in the memory of the mobile device 40 (eg, in an electronic token wallet) (step 404). . The mobile device user can then use those credits to purchase the services or products specified in the credits. The manner in which the user can redeem credits stored on the mobile device 40 will be described in more detail below with reference to FIGS.

  FIG. 6 illustrates an exemplary format and content of one embodiment of a subscription response message 600 suitable for delivering credit to the mobile device 40. This subscription response message 600 may be sent to the mobile device 40 in response to a service request message sent by the mobile device 40 to purchase a service from the service provider 30. Subscription response message 600 may include a number of components that may be categorized into attributes and elements. As shown in FIG. 6, the subscription response message 600 can include optional attributes such as, for example, a request ID 602, a global status code 604 and an adaptation mode 606. The request ID 602 can be an identifier of the corresponding service request message 506. The request ID can identify the subscription response message 600 and associate it with the correct service request message 506 to allow the correct response to reach the party requesting the rights. Using the request ID 602, the user's mobile device 40 can determine whether the correct service response has been received.

  The global status code 604 can provide information regarding the overall result of the request according to some defined return code. Exemplary return codes are described in more detail below with reference to FIG. By using the global status code 604, the mobile device 40 can determine whether the request has been successfully processed. In other words, the global status code 604 may convey the status of the service request message 506 sent by the user's mobile device 40 (ie, success or failure due to an error). For example, if the global status code 604 is present in the subscription response message 600 and is set to the value “0”, this may mean that the request has been successfully processed and completed. In contrast, if global status code 604 is present and set to a value other than “0”, this may mean that there was an error in receiving or processing the request. Even if the service request message 506 is not successfully processed, the mobile broadcast service provider 30 sends a credit even if the mobile broadcast service provider 30 cannot provide the specific service adjustment requested by the mobile device. Note that it is possible to respond with a subscription response message 600. If the global status code 604 is not present in the subscription response message 600, this may mean that there was an error related to one or more purchase item elements 608 associated with the request. The purchase item element 608 is described in more detail below.

  An optional adaptation mode element 606 can inform the mobile device 40 of an operable adaptation mode that can be generic or BDS specific. For example, if the value of this attribute is set to “false”, this may indicate that adaptive mode 606 is generic. For example, if the value of this attribute is set to “true”, this may indicate that adaptive mode 606 is BDS specific. According to various embodiments, the adaptive mode 606 may only exist in the subscription response message 600 if the global status code 604 indicates “success” and the underlying BDS is BCMCS.

  The elements of the subscription response message 600 can further include a purchase item element 608 and optional elements of the DRM profile specific portion 610 or the smart card profile specific portion 612. Purchase item element 608 may represent what was purchased or received, such as the item requested in service request message 506. In other words, the purchased item element 608 can notify the mobile device 40 about whether the user's service request was successful and regarding the requested item delivered. For example, if the service request message 506 requests a digital right (eg, a DRM profile) to play certain content, and the subscription purchase is successful, the purchase item element 608 displays the rights validity end time (Rights validity end time) 622. Rights validity end time 622 is described in more detail below with respect to DRM profile portion 610. For either a DRM profile or a smart card profile, when a purchase or subscription request is unsuccessful, an item-specific status code 616 is provided as an attribute of the purchase item 608 element indicating why the request was not accepted by the mobile broadcast service provider 30. Can exist.

  Purchase item element 608 may further include various attributes and elements. For example, the purchase item element 608 can include a mandatory global ID reference attribute 614 and an optional item-specific status code attribute 616. 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 of the purchase item element 608. Accordingly, the global ID reference 614 can identify the purchased item using a global purchase item ID (not shown) found in the purchase item 608. The global ID reference 614 can be, for example, any uniform resource identifier (URI). The URI is a character string used to identify or specify a resource on the unicast network, for example. Such identification information may allow interaction with the representation of resources on the network using a specific protocol. The item-specific status code can clearly indicate the status of each purchased item using a return code similar to the global status code 604, as described below with reference to FIG. A more specific status code 616 (compared to status code 604) can be provided.

  An optional bonus credit element 618 can be used to transmit credit from the mobile broadcast service provider 30 to the mobile device 40. For example, credit (eg, coupon and / or token) data can be inserted into bonus credit element 618 prior to sending a service response to mobile device 40. In this way, a user can receive credit from the mobile broadcast service provider 30 when sending a request to purchase or subscribe to the service. The credit type (which may be part of the subscription response message 600) may be changed, and requests the requested service type and service (eg, based on user habits and use of a mobile broadcast TV system) And / or the user's identification information. For example, there may be zero or more stand-alone bonus credit subelements (also known as purchase data) in purchase item element 608. These bonus credit sub-elements can include user-specific credit data for bonus services that can result from transactions. These credits are stored in the memory of the mobile device and can be managed based on service guide rules and user membership levels. An exemplary embodiment of the bonus credit 618 message structure is described in more detail below with reference to FIGS.

  The mandatory subscription window element 620 of the purchase item element 608 can include data relating to the time interval during which the subscription or coupon is valid. The service provider 30 can use this element for time-based subscription, and this element can be included in the PPV purchase response message 600. User mobile device 40 can use the information in subscription window element 620 to determine the validity period of the subscription. The subscription window 620 element can further include a mandatory start time attribute (not shown) and an optional end time attribute (not shown). The start time attribute may include a network time protocol (NTP) timestamp that represents the start of the subscription. The end time attribute may include an NTP timestamp that represents the end of the subscription. In one exemplary embodiment, this attribute can be omitted for open-ended subscriptions.

  The optional DRM profile specific portion element 610 can include a service and content protection DRM profile specific portion. This part may be essential to support the DRM profile and is not applicable to the smart card profile. The DRM profile specific portion 610 can further include an optional rights validity end time attribute 622 and an optional rights object retrieval protocol (ROAP) trigger element 624. The rights validity end time 622 attribute includes the LTKM validity end time associated with the purchased content when the BSM accepts the request message (and then needs to be renewed) and May be present to indicate a date. This field may be represented by the first 32-bit integer part of the NTP timestamp. For example, if a rights object (RO) is broadcast, this attribute can be verified. In other cases, this attribute is not required. When optional element ROAP trigger 624 is present, mobile device 40 may be expected to use ROAP trigger 624 to initiate one or more LTKM acquisitions.

  Optional smart card profile specific portion element 612 may include a service and content protection smart card profile specific portion. This part may be essential to support smart card profiles and may not be applicable to DRM profiles. The smart card profile specific subelement 612 can include an optional LTKM element 626. The LTKM element 626 may be a smart card profile mobile broadcast TV LTKM that includes a base64 encoded MIKEY message. This element may be present in the subscription response message 600 if the requesting mobile device 40 and the service provider 30 have agreed on “HTTP” (ie, the Internet) as the LTKM delivery mechanism during the registration procedure.

  FIG. 7A shows a data structure for one embodiment of bonus credit element 618. As shown in FIG. 7A, the bonus credit 618 elements include a protection key 618a, a description 618b, price information 618c, promotion information 618d, an extension 618e, a purchase item reference 618f, and a purchase item. Channel reference 618g, term of use 618h, private extension 618i, ID 618j, version parameter 618k, valid-from parameter 618l, and valid-to A number of parameters and sub-elements, including parameter 618m. The protection key 618a can include an encryption key that can 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, service or subscription 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: a discount amount 619a and a purchase type 619b. Discount amount 619a represents one or more monetary values that represent savings that may be realized when using discounts / coupons, and may potentially be represented as negative numbers in various currencies. ). A special value (such as 0) can be reserved that indicates that the purchase item referenced in the associated discount / coupon is free. In some embodiments, the discount amount 619a may be omitted, in which case the value may be considered to be 0, indicating that the item is free.

  The purchase type table 619b shown in FIG. 7A shows various types and values of purchase or credit transactions that may be used to populate the price information sub-element 618c when a subscription response message is sent to the user's mobile device 40. Show. The various types of purchase type values in the price table 619 are one-time subscriptions, open-end subscriptions, pay-per-time (PPT) live that enables live-based consumption of live content, and non-live content time bases. Using PPT playback that allows consumption, pay-per-play (PPP) playback that allows a certain number of playbacks for non-live content, unlimited playback that allows unlimited playback of non-live content, and service tokens A service token PPT live that enables time-based consumption of live content, a service token PPT playback that enables time-based consumption of non-live content by using a service token, and a user token User token PPT live that enables time-based consumption of user content, user token PPT playback that allows time-based consumption of non-live content using user tokens, and user token PPV live by using user tokens And service purse linked to this service / content SEK / PEK ID key group that may require a user token PPP playback by using the user token and a valid LTKM to use the service token Extra service tokens purchased for addition to the user broadcast and the extra user tokens purchased for addition to the user purse, which can be linked to the mobile broadcast service provider 30 ID May not be linked to service content and may require a valid LTKM to be used) and non-broadcast (ie, real-world) products, such as products from stores, for future use And reservations for commercial use.

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

  Terms of use 618h can include information regarding how credits can be used. For example, some credits cannot be duplicated or transferred to others. Terms of use 618h may define these boundaries to allow credit integrity to remain intact. In addition, this sub-element can specify the type of credit and what purpose this credit can be used. For example, when purchasing content from the mobile broadcast service provider 30, coupons can only be used to receive discounts. Such coupons cannot be used to purchase other products or services.

  Private extension portion 618i may allow vendor specific extensions and application specific extensions to be implemented in addition to the baseline SG standard. Credit ID 618j may include data that can be used to verify the credit and prevent the user from forgering the credit, such as ad hoc ID (nonce ID), encrypted values, and the like. Coupon version 618k identifies a coupon version that can allow a vendor to issue subsequent coupons for similar purchases with different terms and values over time. Information can be included. Thus, coupon version information can be used to support successive versions of the same coupon type. Validity start value 618l may include information regarding the date and time when the credit becomes valid. The end-of-valid value 618m may include information regarding the date and time when the credit becomes invalid and can no longer be used. If the coupon never expires, the valid end value may be omitted.

  Further, the bonus credit element 618 can include an extended URL element (not shown). Such a URL element would give a pointer to a web resource that gives further information related to the credit element. For example, by following an extended URL in the credit element, a WWW page related to the credit or coupon can be reached. If the mobile device 40 has the ability to access the Internet, it uses a URL to access the Internet website to obtain additional information related to credits or coupons using HTTP.

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

  An alternative embodiment of coupon element 650 and its components is shown in FIG. 7B. The sub-elements of this alternative coupon embodiment are to identify the coupon, describe the coupon, indicate the price or discount offered by the coupon, and its weight to combine with other coupons (as described more fully below) And the information needed to verify the coupon, for example in the form of a digital signature. Exemplary information that may be included in the coupon object includes an identifier (ID) (eg, a globally unique identifier, a version number, an expiration date for the first time (effective start date), an effective date for the last time (effective end date) 652) A flag or value 664 indicating that the coupon needs to be verified by the issuer before it can be redeemed, an identifier 654 of the product or service to which the coupon applies, and to make the coupon valid Channel identifier 656, coupon description 658, coupon provider identifier (eg, type of company issuing the coupon) 660, and more fully below with reference to FIG. Multi-use weight value 662 to explain, coupon redeemed Later, an indication 666 how quickly it can be reused, price information 668 including relative price or discount value information, an indication 670 of the item type to which the coupon is valid, when the coupon is redeemed Applied monetary discount price 672, an indicator of the currency currency in which the coupon is valid, an address from which a coupon printable image can be obtained (eg, URL) 674, considered a coupon A URI 676 describing the authority that gave the coupon a digital signature, a user ID field and a user ID type identifier 678, and a digital signature (eg, an XML digital signature) 680 from the issuing authority .

  When an electronic coupon is delivered and processed as a separate coupon document or coupon object, the coupon object can be maintained outside of the service guide. Nonetheless, the coupon object can include a pointer to a fragment in the service guide that identifies information related to the coupon. FIG. 7C shows the relationship between the coupon object 700 and the service guide 710. Specifically, coupon object 700 may include pointers 702, 704, 706 to provisioning fragments 712, 714, 716 in service guide 710 or specific information fields in the provisioning fragment. Such pointers are globally unique that do not change when the service guide is updated so that the information referenced by the coupon object 700 is always available via the pointers 702, 704, 706 included in the coupon. It can be in the form of a pointer.

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

  Multipurpose signature 618o can be used to protect coupons when the coupons are transported over a hostile network. Multipurpose signature 618o may be retrieved on demand and / or cached by a merchant server. Along with the hierarchy of 509 digital certificates, it can be used to authenticate a coupon using a cryptographic signature (ie, an encryption digest of all or part of the coupon field). In one embodiment, the coupon issuer uses the multi-purpose signature 618o to generate a coupon that cannot be changed without detection (eg, using a well-known public key cryptography method). Can do. In one embodiment, X.X.X allows the coupon recipient (eg, mobile device and merchant) to verify that the coupon was issued by a particular institution, as described in more detail below. A multi-purpose signature 618o can be created using the 509 signature hierarchy. In this embodiment, X. The signature algorithm can be specified in the 509 certificate.

  FIG. 9 is a table 604a of various global status codes 604 that can be included in the subscription response message 600 and their associated status messages. For example, a subscription response message 600 that includes the global status code “000” may indicate that the request process was successful. Subscription response message 600 including global status code “003” may indicate that the requested purchase item is unknown. The “003” code may also be received, for example, if the device has a cached service guide service with outdated information, in which case the user can reacquire the service guide. Subscription response message 600 including global status code “009” may indicate that the charging step has failed. For example, when the agreed credit limit is reached, the account can be frozen, in which case the user can contact the service provider 30 to resolve the problem. The “009” code can also be used between various companies involved in a transaction. A subscription response message 600 that includes the global status code “011” may indicate that the operation that the device attempted to perform is not allowed under a contract between the service provider 30 and the user. Upon receiving such an error message, the user can contact the service provider 30 to change the contract terms. The “011” code can also be used between companies. The subscription response message 600 including the global status code “015” can indicate that the requested service is not available due to transmission problems, in which case the request can be resumed later. The “015” code can also be used between companies. A subscription response message 600 including the global status code “016” may indicate that the same request has been processed previously, in which case the user or entity may check whether the request has already been processed. it can. This can be done by determining whether LTKM has been received, otherwise, re-enter the request. A user subscription response message 600 including the global status code “021” may indicate that the information provided is invalid and cannot be used by the system. In such a situation, the user can reconfirm the request and send it again. Subscription response message 600 including global status code “022” may indicate that the requesting key material and message are not valid and cannot be fulfilled. In such a scenario, the user can reconfirm the request and retransmit if necessary. Subscription response message 600 with global status “031” indicates that the user has attempted to use bonus credit 618 to carry the coupon, but the coupon has an expiration date and is no longer valid for the purchase transaction. Can show that. The subscription response message 600 containing the global status code “032” used the verified bonus credit (carrying a coupon) by the user to purchase an available content object, but the coupon It can be shown that it is already used in a transaction and therefore is no longer valid.

  In one embodiment, credits can be delivered or pushed to the user's mobile device 40 without receiving a voluntary service request from the user. In other words, the mobile broadcast TV system “bootstrap” the user's mobile device 40 and pushes out credits to the user's mobile device 40 without the user's mobile device 40 sending a request message ( push out). Such a delivery method may involve third party 50 and mobile broadcast service provider 30 sending credit to mobile device 40 using broadcast network 80 for delivering messages to all users, or a specific user or A unicast network 70 for delivering messages to a group of users may be used to allow credits to be sent to the mobile device 40. Bootstrapping the user's mobile device 40 can be done in various ways. In one embodiment, solicited pull messages may be broadcast to the user's mobile device 40, as described below with reference to FIGS. The solicitation pull message can solicit a credit purchase request from the user's mobile device 40. In other embodiments, as described below with reference to FIGS. 13-14, to allow the user's mobile device 40 to receive credit without having to take explicit action, Credit grant push messages can be broadcast to the mobile device 40.

  To illustrate the distribution of credits using the bootstrapping method, the following exemplary embodiment describes the distribution of free tokens to users. To view mobile TV programs, free tokens can be redeemed in much the same way as purchased tokens. In the following embodiments, the process for delivering tokens is used as an example, but using the same process to deliver other types of credit, such as coupons that can be redeemed for products or services, for example. it can. Thus, the following example does not limit the scope of the invention to token delivery.

  FIG. 10A is a process flow diagram of an exemplary implementation method for bootstrapping a user's mobile device to receive a free token using a solicitation pull message. FIG. 11A is a message flowchart of messages that may be exchanged between various mobile broadcast TV system components to deliver tokens according to the method shown in FIG. 10A. This embodiment is described below with reference to both FIG. 10A and FIG. 11A.

  To initiate an involuntary token purchase request, the mobile broadcast service provider 30 sends a solicitation pull message to the user's mobile device 40 (steps in FIG. 10A related to message 1100 in FIG. 11A). 314). The solicitation pull message 1100 can be transmitted over either the broadcast network 80 or the unicast network 70. The solicitation pull message 1100 is a message that prompts the mobile device 40 to send a purchase request message, thereby initiating the credit distribution process described above with reference to FIGS. 4 and 5. The user's mobile device 40 receives and processes the solicited pull message (step 406). Optionally, the user is prompted to accept or reject the transmission pull (optional decision 408). This optional user selection may be useful, for example, for mobile device users where privacy or security issues may outweigh the desire to receive credit. If the user responds to the prompt by rejecting the solicitation pull, the mobile device 40 simply ignores the solicitation pull message. However, if the user responds to the prompt by accepting a solicitation pull (ie, decision 408 = “YES”), the mobile device 40 sends a token purchase request to the mobile broadcast service provider 30 (message 1102 in FIG. 11A). Step 410 in FIG. 10A). As described above with reference to FIGS. 4 and 5, the token purchase request message 1102 can be sent to the service provider 30 via the unicast network 70 or other network such as the Internet 90. The token purchase request message 1102 may include information (eg, an identifier) specified in the solicitation pull message based on the rules defined in the solicitation pull message 1100 sent by the mobile broadcast service provider 30. Or, for example, a purchase request of 0 can be specified when the token purchase request is for a free token. Upon receiving the token purchase request message 1102 (step 316), the mobile broadcast service provider 30 processes a request to determine if an error exists (decision 318). If the token purchase request message 1102 has not been successfully received (ie, decision 318 = “NO”), a token purchase response with an error message is sent to the mobile device 40 (step 412, message 1104). This error message may include one or more of the code and status messages described above with reference to FIG. If the token purchase request is processed successfully (ie, decision 318 = “YES”), then the mobile broadcast service provider 30 then sends a token purchase response message (in FIG. 10A related to message 1104 in FIG. 11A). Step 320), which is received by the user's mobile device 40 (Step 414). The token purchase response message 1104 can include attributes and elements described in more detail below with reference to FIG. After sending the token purchase response message, the mobile broadcast service provider 30 sends an LTKM message containing the token to the mobile device 40 along with terms and conditions under which the free token can be used (in FIG. 11A). Step 416 in FIG. 10A related to message 1106). The LTKM can be transmitted via the unicast network 70 or another network such as the Internet 90. Upon receiving the LTKM (step 416), the mobile device 40 stores the token in its memory (step 418 in FIG. 10A relating to the internal message 1108 in FIG. 11A). Optionally, mobile device 40 sends a validation message to mobile broadcast service provider 30 to indicate a safe receipt of the token (step 420 in FIG. 10A related to message 1110 in FIG. 11A). This verification message 1110 can be transmitted over the unicast network 70 or other network such as the Internet 90. The mobile broadcast service provider 30 receives the verification message 1110 (step 324).

  FIGS. 10A and 11A illustrate one exemplary embodiment for exchanging tokens via token purchase request and purchase response messages, but using a solicitation pull process, for example instead of tokens. A generic subscription request message (ie, a service request) can be sent as a mechanism for receiving credit, such as for receiving a coupon. FIG. 10B is a process flow diagram of an exemplary implementation method for bootstrapping a user's mobile device to receive a coupon via a service request using a solicitation pull message. FIG. 11B is a message flowchart of messages that may be exchanged between various mobile broadcast TV system components to distribute coupons according to the method shown in FIG. 10B. Processes and messages with similar numbered references correspond to those described above with reference to FIGS. 10A and 11A.

  Referring to FIGS. 10B and 11B together, in response to receiving the solicited pull message 1100 (step 406 in FIG. 10B), the mobile device 40 sends a service request message to the mobile broadcast service provider 30 ( Step 411 and step 317 in FIG. 10B corresponding to message 1103 in FIG. 11B). The mobile broadcast service provider 30 responds by sending a service response message to the mobile device 30 (step 321 and step 415 in FIG. 10B corresponding to message 1105 in FIG. 11B). Mobile broadcast service provider 30 then sends an LTKM message containing the coupon (or other valuable item) to mobile device 30 (steps 323 and 417 in FIG. 10B corresponding to message 1107 in FIG. 11B). . Mobile device 30 stores the LTKM and coupon in memory (step 419 in FIG. 10B and internal message 1109 in FIG. 11B) and optional verification as described above for steps 420 and 324 and message 1110. Reply with a message.

  FIG. 12 illustrates various attributes and elements that may be included in one embodiment of the token purchase response message 1104. The token purchase response 1104 can include an optional request ID attribute 602 and a mandatory global status code attribute 604. As described above with respect to FIG. 6, the request ID attribute 602 can be the identifier of the corresponding service request message. Thus, the request ID attribute 604 can identify the token purchase response message 1104 and associate it with the correct token purchase request message 1102 to allow the correct response to reach the party requesting the right. Using the request ID attribute 602, the user's mobile device 40 can determine whether a token purchase response message 1104 has been received. As described above with respect to FIG. 6, the global status code 604 can provide information regarding the overall outcome of the token purchase request in accordance with a number of defined return codes. Exemplary return codes are described in more detail above with reference to FIG. By using the global status code 604, the mobile device 40 can determine whether the request was successfully processed or failed due to some error. In other words, the global status code 604 can communicate the status of the service request (ie, success or failure due to an error) to the user's mobile device 40.

  The token purchase response 1104 can also include optional elements, such as a DRM profile specific subelement 610, a smart card profile specific subelement 612, and a bonus credit element 618, for example. The DRM profile specific subelement 610 and the smart card profile specific subelement 612 are mutually exclusive. Thus, the token purchase response message may include only either the DRM profile specific subelement 610 or the smart card profile specific subelement 612. The service and content protection DRM profile specific subelement 610 may be mandatory to support the DRM profile and may not be applicable to the smart card profile.

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

  The token purchase response message can include an optional granted token element 1202 and an LTKM element 626. The token donation element 1202 can include a number of attributes in response to the token purchase request message 1102, such as, for example, information regarding the tokens that are granted. These attributes can include a type 1204, a quantity 1206, and a billing type 1208. The type attribute 1204 can specify the token type granted in the token purchase transaction. The various token types that can be granted and their assigned values are for reserved tokens (value 0), tokens for DRM profiles (value 1), and smart card profiles that are added to live PPT parses. Service token (value 2), service token for smart card profile added to replay PPT parse (value 3), and user for smart card profile added to user parse associated with service provider 30 ID Tokens (value 4), tokens reserved for future use (values 5 to 127), and tokens reserved for commercial use (values 128 to 255). The quantity attribute 1206 can include information specifying the number of tokens awarded in the token purchase transaction. For type attribute 1204, the value specified in the attribute may correspond to the number of tokens awarded. Charging type attribute 1208 may include information regarding the charging type to be associated with the token purchase transaction. The billing type is unspecified (value 0), prepaid (value 1), postpaid (value 2), reserved for future use (value 3 to value 127), and reserved for commercial use. (Value 128 to value 255). As described above with respect to FIG. 6, the LTKM 626 element may be a smart card profile mobile broadcast TV LTKM that includes a base64 encoded MIKEY message. This element may be present in the token purchase response message 1104 if the requesting mobile device 40 and the service provider 30 agree on “HTTP” (ie, the Internet) as the LTKM delivery mechanism during the registration procedure.

  Similar to the subscription response message 600 described above with reference to FIG. 6, the token purchase response message 1104 also includes an optional bonus credit element 618 for sending credit, such as a token or coupon, to the user. be able to. For example, credit (ie, coupon and / or token) data may be inserted into bonus credit element 618 prior to sending token purchase response 1104 to user mobile device 40. In this way, when the user's mobile device 40 responds to a solicitation pull message sent by the mobile broadcast service provider 30, the user can receive credit from the mobile broadcast service provider 30. The credit type, which can be part of the token purchase response message 1104, can be changed and, for example, the token type being pushed to the user or solicitation (based on user habits and use of mobile broadcast TV system) It can be tied to the identity of the user who sent the pull message 1100 or responds with the token purchase request message 1102 or both. For example, zero or more stand-alone bonus credit parameters (also known as purchase data) may exist as attributes of the purchase item element 608. These bonus credit parameters may include user specific credit data for bonus services that may result from this token purchase transaction. Credits can be stored in the memory of the user's mobile device 40 and managed based on service guide rules and the user's membership level. Exemplary embodiments of the bonus credit 618 message structure have been described in more detail above with reference to FIGS.

  FIG. 13 illustrates an example embodiment process flow for bootstrapping a user's mobile device 40 to receive a free token using token grant push messages. FIG. 14 is a message flowchart illustrating messages that may be exchanged between various mobile broadcast TV system components for the delivery of credits according to the method shown in FIG. This embodiment will be described with reference to both FIG. 13 and FIG.

  To initiate delivery of the token to the mobile device 40, the mobile broadcast service provider 30 sends a token grant push message to the mobile device 40 (step 321, message 1400). The mobile device 40 receives and processes the token grant push message (step 413). The token grant push message notifies the mobile device 40 that the LTKM will be sent so that the mobile device 40 can prepare to receive the credits in the LTKM. Following the token grant push message 1400, the mobile broadcast service provider 30 sends an LTKM identifying the free token and terms of use to the mobile device 40 (step 322, message 1106). Upon receipt of LTKM 1106, mobile device 40 processes the information (step 416) and stores, for example, a free token in a memory such as mobile device secure function 90 (eg, smart card memory) (step 418, internal message 1108). The mobile device 40 responds to the mobile broadcast service provider 30 with a verification message to indicate that the LTKM and the free token have been successfully received and stored (step 420, message 1110). Alternatively or optionally, if the token is not successfully stored in memory, the mobile device 40 includes that information in a verification message (not shown). The mobile broadcast service provider 30 receives the validation message 1110 (step 324) and takes appropriate steps based on the content of the message. For example, if the validation message 1110 indicates that the token has been successfully received and stored by the mobile device 40, the service provider 30 takes no further action. However, if the validation message 1110 includes information indicating that the token was not successfully received or stored in the memory of the mobile device 40, the mobile broadcast service provider 30 is appropriate to improve the situation. An action (eg, retransmitting LTKM 1106) may be taken.

  Once credits such as free tokens or coupons are delivered to the mobile device 40, the user can use them to purchase mobile TV programs, services or products. According to various embodiments, various methods for redeeming credits can be employed. One exemplary redemption method involves broadcasting an STKM that can purchase only service content from a particular mobile broadcast service provider 30 using credits. Another example is using the unicast network 70 to the mobile device 40 from on-board electronic perspective (implemented on a secure memory on the terminal or in a smart card) as part of the payment for purchase. Sending an LTKM parse mode to decrement a specific credit. The LTKM parse mode message is a message that includes an instruction to cause the mobile device to decrement credit from its electronic parse. Another example includes broadcasting an STKM null program message that is a message instructing the mobile device 40 to decrement a particular credit from its electronic parse as part of the payment. Each of these credit redemption methods will be described in more detail below with reference to FIGS.

  FIG. 15 is a process flow diagram of an exemplary embodiment for performing credit redemption using STKM broadcast. FIG. 16 is a message flowchart of messages exchanged between various mobile broadcast TV system components to perform credit redemption in the method shown in FIG. This embodiment will be described below with reference to both FIG. 15 and FIG.

  According to various embodiments, credits delivered or pushed to mobile device 40 can include credits that can only be redeemed for purchasing free or discounted programs or content from mobile broadcast service provider 30. In such a scenario, the mobile broadcast service provider 30 broadcasts an STKM stream (message 1600) and can further purchase a nominal or promotional program and content stream that can be purchased using credits stored on the mobile device 40 ( The message 1601) is broadcast (step 326). Message 1600 includes broadcast distribution of the STKM stream. A message 1601 transmits the encrypted content as a continuous stream. The mobile device 40 uses the received STKM stream 1600 to determine whether credits in memory can be used to access a particular encrypted content stream (message 1601) associated with the STKM stream broadcast. Process (step 420). The broadcast STKM stream 1600 can be delivered by the broadcast network 80 to any mobile device 40 registered with the broadcast network. However, not every mobile device 40 that has received STKM can decrypt the included TEK to access the associated encrypted content stream (message 1601). In order to access the encrypted content (message 1601) associated with the STKM stream 1600, the receiving mobile device 40 must possess the correct code and permissions. Such codes and permissions are defined by LTKM rules stored on the mobile device 40. For example, the LTKM rules that can be used can be LTKM rules that are distributed with credits, as described above with reference to FIGS. Upon receiving the STKM stream 1600, the mobile device 40 processes it in the mobile device secure function 90 (step 422, internal message 1602) to determine whether the LTKM rules allow access to the STKM stream 1600 (decision). 422). If the mobile device 40 determines that the LTKM rule does not allow access to the STKM stream (ie, determination 422 = “NO”), the mobile device 40 ignores the STKM stream (not shown). However, if the LTKM rule allows access to the STKM stream (ie, decision 422 = “YES”), the mobile device 40 may receive the STKM stream from the credit parse, subject to the availability of credits being parsed. Decrement the amount of credit required to decrypt one or more TEKs from (step 424, internal message 1604). The mobile device 40 then uses TEK to decrypt at least a portion of the encrypted content stream (message 1601).

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

  When the encrypted content 1601 is decrypted and accessed by the mobile device 30, the mobile broadcast service provider 30 settles the credit exchange with the merchant 50 (step 338, step 516, message 1606). This settlement between the service provider 30 and the third party 50 or content provider 60 can be accomplished using any conventional business transaction process, including known electronic commerce transaction methods.

  FIG. 17 is a process flowchart of an exemplary embodiment that allows a user to consume credits to purchase a service or product from a merchant. FIG. 18 is a message flowchart of messages that may be exchanged between system components to implement the steps shown in FIG. This embodiment will be described below with reference to both FIG. 17 and FIG.

  In this exemplary embodiment, promotional credits distributed to the mobile device 40 in LTKM can be used to purchase products while shopping at a merchant or on a vendor website. The process of receiving and storing credits has been described above with reference to FIG. 10 or FIG. Such credits pay for or against services or products when shopping, such as during physical shopping at a vendor location (ie, at a POS) or while shopping online. Can be used to receive discounts. The user initiates a shopping session with the merchant 50 via the user's mobile device 40 (step 428, step 508, message 1800). The user indicates a desire to finalize the purchase and sends information about the coupon or credit stored in the mobile device 40 from the mobile device 40 to the merchant 50 (message 1802). This message can be known variously over the internet during an online shopping session or including, for example, near field communication (NFC) links, displayed bar codes, or manual entry of coupon IDs. The transmission method can be transmitted from the mobile device 40 to the merchant POS system. The merchant 50 determines whether the submitted credit can be used as part of the payment for this transaction (decision 510). If credit is not available to pay for this transaction, the merchant 50 allows the user to pay using other payment means, such as using a credit card (step not shown). However, if the merchant 50 determines that the user's credit or coupon is available (ie, determination 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 can be sent over the Internet 90 or other network and can identify a proffered coupon, user and / or mobile device 40. Upon receiving the payment request (step 330), the mobile broadcast service provider 30 creates an LTKM parse mode message and sends it to the user's mobile device 40 (step 432, message 1806). The LTKM parse mode message 1806 can be sent to the user 40 using the unicast network 70 and includes instructions to instruct the user's mobile device 40 to decrement the appropriate credit from the electronic parse of the mobile device 40. Can do. The mobile device 40 receives the LTKM parse mode message 1806 (step 432) and decrements the credit from the electronic parse based on the LTKM rules (step 434, internal message 1808). If the credit is not fully or successfully decremented, the mobile device 40 sends a signal to the mobile broadcast service provider 30 (not shown). If the credit is not fully or successfully decremented from the parse of the mobile device 40, the mobile broadcast service provider 30 retransmits the LTKM parse mode (not shown). However, if the credit is successfully decremented, the mobile device 40 sends a verification message to the mobile broadcast service provider 30 (step 436, message 1810). This verification message 1810 can be transmitted via the unicast network 70. The mobile broadcast service provider 30 receives the validation message 1810 (step 334), sends a payment response message to the merchant 50 (step 336, message 1812), and the merchant sends the payment response message over the Internet or other network. Receive (step 514). Payment response message 1812 may provide information to merchant 50 that the credit has been successfully decremented from the user's mobile device 40 parse. Merchant 50 can complete the transaction with the user. The credit exchange settlement between the mobile broadcast service provider 30 and the merchant 50 can be done at the time of sale, for example, with the sending of a payment response message 1812, etc., or later (steps 338, 516).

  In the exemplary embodiment shown in FIG. 19, a STKM null program message can be sent to the user's mobile device 40 to decrement the credit to pay for the purchase of the product or service. Since the STKM null program message is broadcast to all terminals, only the mobile devices involved in the shopping transaction should be affected by this special payment message. This is ensured by carrying a unique shopping transaction ID in the STKM null program message. All other mobile devices for which the user was not involved in the shopping transaction can simply ignore this STKM message. FIG. 20 is a message flowchart of messages that can be exchanged in the method shown in FIG. This embodiment will be described below with reference to both FIG. 19 and FIG.

  The process of receiving and storing credits has been described above with reference to FIG. 10 or FIG. As described above, credits stored on the mobile device 40 can be used to pay for services or products when shopping at a vendor location (POS) or while shopping online. . The user starts a shopping session with the merchant 50 by the user's mobile device 40 (step 428 in FIG. 19 and step 508 corresponding to the message 1800 in FIG. 20). The user indicates a desire to confirm the purchase, and sends information regarding the coupon or credit stored in the mobile device 40 from the mobile device 40 to the merchant 50 (message 1802 in FIG. 20). This message can be sent via the Internet during an online shopping session or by various known transmission methods including, for example, near field communication (NFC) links, displayed bar codes, or manual entry of coupon IDs. It can be transmitted from the mobile device 40 to the merchant POS system. Merchant 50 determines whether the credit can be used to pay for this transaction (decision 510). If credit cannot be used to pay for this transaction (not shown), the merchant 50 allows the user to pay using other means of payment, such as using a credit card. However, if the merchant determines that the user can pay using the credit (ie, decision 510 = “YES”), the merchant 50 sends a payment request message to the mobile broadcast service provider 30 (FIG. Step 512 in FIG. 19 corresponding to message 1804 in 20. This payment request message 1804 can be sent over the Internet 90 or other network and can identify the presented coupon, user and / or mobile device 40. Upon receiving the payment request (step 330), the mobile broadcast service provider 30 broadcasts the STKM null program message to the mobile device 40 (step 331 in FIG. 19 corresponding to the message 2000 in FIG. 20). The STKM null program message 2000 can be transmitted over the broadcast network 80 in an encoded manner so that only the user's mobile device 40 can receive and decode it. The mobile device 40 receives the STKM null program broadcast message 2000 (step 438), decrypts the content using the key in the LTKM associated with the credit stored in the mobile device 40, and the LTKM rule is STKM null. It is determined whether access to the program broadcast message 2000 is permitted (decision 422). If the LTKM rule allows access to the STKM null program message 2000 (ie, decision 422 = “YES”), send the message to the parsed credit (internal message 2002) and decrement the credit from the parse ( Step 434). When the credit is decremented, a verification message is sent to the mobile broadcast service provider 30 (step 436 in FIG. 19 corresponding to message 1810 in FIG. 20). This verification message 1810 can be transmitted via the unicast network 70. The mobile broadcast service provider 30 receives the verification message 1810 (step 334) and sends a payment response message to the merchant 50 (step 336 in FIG. 19 corresponding to the message 1812 in FIG. 20). This payment response message 1812 can be sent over the Internet 90 or other network. Merchant 50 receives the payment response (step 514), and the payment response notifies merchant 50 that the credit has been successfully decremented so that merchant 50 can confirm the sale. The credit exchange is then settled between the mobile broadcast service provider 30 and the merchant 50 via any known financial transaction mechanism (in FIG. 19 corresponding to message 1606 in FIG. 20). Step 338 and Step 516).

  If the mobile device 40 cannot or should not access the STKM null program message 2000, it can ignore the message. Accordingly, the credit is not decremented and no verification message 1810 is sent to the service provider 30. Since the mobile broadcast service provider 30 does not receive the verification message, it will send a payment response message 1812 notifying the merchant 50 that the credit has not been transferred. In such a scenario, the merchant 50 may decline the credit or coupon and require the user to use another form of payment for the service or product.

  Several rules can be defined to manage the use of credits. For example, the credit may include an expiration date or may be used only once. For illustrative purposes, the following example refers to the use of coupons, but the scope of the present invention is not limited to this form of credit. FIG. 21 is a process flow diagram of an implementation method for identifying an expired coupon and deleting it from the electronic parse of the mobile device 40. Mobile device 40 receives the coupon (step 2100) and stores it in memory (step 2102). Later, the mobile device receives a request to use the coupon (step 2104). As described above, the request may be received from the broadcast service provider 30 in the form of LTKM or STKM. Upon accessing the coupon in response to the LTKM or STKM, the mobile device 40 determines whether the coupon has expired (decision 2108) before allowing the coupon to be used. If the coupon has expired (ie, decision 2108 = “YES”), the coupon is deleted from memory (step 2112) and a report of deletion of the expired coupon is sent to the mobile broadcast service provider 30 (step 2114). Such a report of deletion of expired coupons can be sent via the unicast network 70. If the coupon is not expired (ie, decision step 2108 = “NO”), as described above, the coupon is applied to the purchase based on the received LTKM or STKM (step 2110).

  FIG. 22 is a process flow diagram of an exemplary implementation method for identifying and deleting coupons that are used. Mobile device 40 receives the coupon (step 2100) and stores it in memory (step 2102). The mobile device receives a request to use the coupon (step 2104). As described above, the request may be received from the broadcast service network 30 in the form of LTKM or STKM. When accessing a coupon in response to an LTKM or STKM, the mobile device 40 determines whether the coupon has already been used or previously replicated before deducting the coupon to pay for a purchase transaction ( Decision 2200). This determination can be based on whether a coupon can be used once by one user, all users can use it once, or multiple times during the promotion period, or can be assumed by the coupon creator It can be defined so that it can be used according to the usage pattern. If the coupon was used or was previously replicated (ie, decision 2200 = “YES”), the coupon is deleted from memory (step 2112) and a report of the deletion is sent via the unicast network 70 to the mobile broadcast service provider 30. (Step 2114). If the coupon has not been previously used or replicated (ie, decision step 2108 = “NO”), apply the coupon to the purchase based on the received LTKM or STKM as described above (step 2110).

  Although the above description of the embodiment refers to a mobile device communicating with a mobile broadcast service provider over a unicast network, other communication links may be used. For example, such messages can be delivered to a server pool in a mobile broadcast service provider network via anycast network communications without departing from the scope of the claims and the present invention.

  While the above embodiments deliver coupons or tokens to mobile devices via long term decryption key messages (eg, LTKM) and control coupon or token decrement via short term decryption key messages (eg, STKM), the claims Implementations that use dedicated coupon transaction messages that are not currently part of known mobile broadcast standards can be included. If such a standard is modified to include a dedicated coupon transaction message, such a message will include many of the elements of the short-term and long-term decryption key messages described herein and will be processed in the same way. Will.

  By using public key cryptography and electronic signature coupons, the user and / or retailer can each verify that the coupon is authentic without contacting the original issuer, Alternatively, a copy of all issued coupons can be stored. In one embodiment, a coupon can be issued that can only be used by a single person or user group and cannot be reused by others. In such cases, the digest in the multipurpose signature 618o not only covers the entire contents of the coupon object, but also the account identification information of the user (or user group) authorized to use the coupon, as well as the coupon Other aspects of recording can also be covered. When coupons are authenticated using digital signature techniques, signatures are not verified using unauthorized account identification information, so third parties attempting to submit coupons that were not issued to them are easily detected become.

  In one embodiment, X. A multi-purpose signature 618o can be formed using the 509 signature hierarchy. X. 509, in particular, route X. A format of public-key certificates and certification path validation algorithms that allow the recipient to verify that the signature has been generated by an authority trusted by 509 Is a well-known ITU-T standard for public key infrastructures that specify. In short, a digital signature is obtained by a chain of certificates, each certificate pointing to a higher certificate, and the chain of certificates is stored in a trusted X.D. stored by a coupon redeemer. 509 Pending. X. By utilizing 509 engines, route X. 509 institutions can allow other companies to issue valid coupons by handing over child certificates. In this way, the coupon verification entity can pass the coupon signing certificate to the company that wishes to issue coupons, which in turn uses those certificates to issue verifiable coupons. You can issue child certificates to individual business units or departments. X. The merchant point-of-sale system or merchant server 50 presented with a coupon verified by a digital signature using the 509 signature hierarchy is the The cached verification certificate provided by the 509 institution can be used to verify the coupon without having to establish a trust relationship with the individual coupon issuer. Therefore, X. The use of digital signatures formed using the 509 signature hierarchy is the same as merchant systems that When trusting 509 institutions, it is possible to verify coupons, thereby greatly simplifying the redemption of delivered coupons according to various embodiments. This allows the merchant system to verify the coupon without having to communicate with the coupon issuer.

  In one embodiment, a coupon with a digital signature can be created and broadcast to the mobile device 40 via a mobile multimedia broadcast network. FIG. 23 shows an implementation method for broadcasting a coupon with a signature. In one embodiment, the merchant server 50 creates a coupon template that includes access information (e.g., URL and coupon ID number) for coupon acquisition (step 2302) and generates the coupon template over a network (e.g., the Internet). Transmit to the mobile broadcast provider 30 (step 2304). The mobile broadcast provider 30 receives the coupon template from the merchant server 50, encrypts it, and broadcasts it (step 2306). Mobile device 40 receives the encrypted coupon template from the broadcast transmission (step 2308). The mobile device 40 decrypts the coupon template by using the TEK (step 2310). As described above, the TEK is retrieved based on the LTKM and STKM received by the mobile device 40 from the mobile broadcast provider 30. If the mobile device is one of the inbound recipients of the broadcast coupon, the mobile device 40 will receive a TEK (LTKM and STKM method) that allows the device to decrypt the coupon template. Can be received). If the mobile device is not part of the group that is the subject of the coupon, the mobile device 40 will not have a corresponding TEK and therefore will not be able to decrypt the coupon template. Upon decrypting the coupon template, the mobile device 40 obtains the coupon access information by using the Internet 90, eg, via a unicast network, to access a website hosted by the merchant server 50. Use to request an available electronic coupon (step 2312).

  In this embodiment, the merchant server 50 can act as a coupon data repository that receives a request for an electronic coupon of the mobile device 40 (step 2314). The merchant server 50 sends a request for device identification information and coupon data not carried in the initial request to the mobile device 40 via an open internet connection (step 2316). The mobile device 40 receives the request for identification information and coupon data via the Internet 90 (step 2318), and in response, transmits the requested data to the merchant server 50 (step 2320). Such mobile device identification information can be any form of information that identifies the device and / or user to the merchant server 50. Examples of such information include device identifier (eg, MAC ID), device phone number, user account number, membership number, user name, secret stored in device memory as known to merchant server 50 There is a secret number (for example, a personal identification number (PIN)). During the transaction, the mobile device may need to submit one or more of these device identifiers.

  Various methods may be used to send device identification information data to the merchant server 50. For example, the device identification information data can be automatically transmitted to the merchant server 50 in response to a request for information. In such an implementation, the mobile device 40 can be configured to automatically respond to the request of the merchant server 50 by providing the requested identification parameter in a response message to the merchant server 50. Alternatively, the mobile device can notify the user about the request and send device identification information data to the merchant server 50 only upon user instruction. In such an implementation, the mobile device 40 notifies the user about the request for identification information data from the merchant server 50 and approves or rejects the user to send the requested data. Can be configured to respond only when user input is received that enables transmission of such identification information data to the merchant server 50.

  The merchant server 50 uses the identification information and the coupon data to create a coupon including a digital signature (step 2324). The digital signature digest may include request source device identification information and a coupon ID. As explained above, the digital signature is root X. X. 509 related to retroactive institutions. It can be generated using a certificate with a 509 signature hierarchy. As described below, a digital signature with device information and a coupon ID can be used to verify the authenticity of the coupon before accepting the coupon at the point of sale. The verification method in the point of sale will be described in more detail below with reference to FIG. The merchant server 50 transmits the signed coupon to the broadcast provider 30 (step 2326). Broadcast provider 30 relays the signed coupon from merchant server 50 to mobile device 40 using a unicast network (step 2330). Alternatively, the merchant server 50 can send the signed coupon to the mobile device 40 via an open communication link over the Internet 90 directly. The mobile device 40 receives and stores the signed coupon (step 2330) and notifies the user about the receipt of an electronic coupon currently available in the transaction (step 2332).

  In an alternative embodiment, instead of providing a URL, the coupon template can include a different communication indicator or address, such as a phone number. In such an embodiment, the mobile device 40 exchanges device identification information and receives a signed coupon with the merchant server 50 via a communication network, such as using an SMS or MMS communication method, for example. Can communicate.

  FIG. 24 illustrates another implementation that allows the merchant server 50 to create a signed electronic coupon for broadcast to the mobile device 40 without having to encrypt the broadcast coupon. In this embodiment, the merchant server 50 uses conventional signature methods to provide coupon data, a coupon identity number, and (if known) designated recipient mobile device identification information data. A coupon with a digital signature to include is created (step 2402) and the signed coupon to be broadcast is sent to the mobile broadcast provider 30 (step 2404). As explained above, the digital signature is root X. X. 509 related to retroactive institutions. It can be generated using a certificate with a 509 signature hierarchy. As in the previous embodiment, the mobile device identification information data may include any one or more device identifiers, such as a device MAC ID, phone number, PIN, account number, or group number. it can. The group number may be assigned to the mobile device 40 that subscribes, eg, through a contract or interaction with the merchant, or assigned to a group of mobile devices or users (ie, a group ID). For example, a merchant has a frequent customer rewards program that allows a user to receive a group identifier that can be stored in the user's mobile device to sign up and receive electronic coupons. Can do. In this example, the merchant can issue an electronic coupon signed with a customer reward program identifier for broadcast so that only registered customers receive coupons that can be redeemed over the broadcast network.

  The mobile broadcast provider 30 receives the signed coupon from the merchant server 50 and broadcasts it as part of the normal broadcast transmission (step 2406). In this exemplary embodiment, the user and the merchant server can verify the coupon usage using a digital signature to ensure that only some mobile devices receive and process the coupon. Thus, the broadcast provider 30 does not need to encrypt the signed coupon before broadcasting it.

  The mobile device 40 can be pre-registered with the merchant server 50 to receive and decrypt the digitally signed coupon from the merchant server 50. As part of pre-registration, the merchant can provide a decryption key for storage on the user's mobile device. Such a decryption key is, for example, X. It can be a standard public decryption key that the merchant server 50 can share with the mobile device 40, such as a 509 verification certificate. Further, during the pre-registration process, the mobile device 40 can share device data with the merchant server 50. The merchant server 50 can store and use such device data received during pre-registration to create a coupon including that data, and the digital signature includes the device data along with the coupon data. Since digital signatures can only be verified using device data, this method allows the generation of electronic coupons that can only be used by specific mobile devices. This makes it possible to broadcast coupons given to individual users or small groups of users via the broadcast network 80 in an unencrypted manner.

  Upon receiving the broadcast digitally signed coupon (step 2408), the mobile device 40 decrypts 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, eg, coupon data, device ID (step 2412), and whether the ID retrieved from the signature matches that stored on the device. It is determined whether or not (determination 2414). Digital signature is X. When generated using a 509 signing certificate, the mobile device also has a coupon that has a root X. It can be verified that it was issued by an entity trusted by a 509 agency and thus trusted by a trusted company. A mobile device that does not have the proper decryption key can receive the broadcasted coupon, but cannot decrypt the signature and therefore ignore the data.

  If the received device data being signed matches the mobile device data (ie, decision 2414 = “YES”), the mobile device 40 stores the coupon in the memory of the mobile device 40 (step 2416) and is currently in the transaction. The user is notified of receipt of an available electronic coupon (step 2418). If the device data obtained from the decrypted signature does not match the data of mobile device 40 (ie, decision 2414 = “NO”), mobile device 40 treats the coupon as a coupon not intended for mobile device 40. Ignore (step 2420). If the mobile device 40 does not have the decryption key required to decrypt the coupon signature, the mobile device 40 ignores the received coupon. Encryption to provide a verifiable electronic coupon to a specific user or group of users via a mobile broadcast network without using broadcaster encryption methods (eg, LTKM and STKM methods described above) Various combinations of and digital signatures can be similarly employed.

  At a merchant point of sale (POS), coupons with digital signatures can be redeemed in a variety of ways. For example, depending on the coupon type, a product can be purchased at a point of sale at a discount or free of charge. FIG. 25 shows an implementation method for redeeming a signed coupon during a purchase transaction at a point of sale. During a sales transaction (eg, during “checkout”), the user presents the mobile device 40 that stores the signed coupon to the POS system 95. The mobile device 40 and the POS system negotiate the communication link, for example using a well known near field communication (NFC) link, and the mobile device 40 then electronically coupons with the device identification information data over the communication link. Data is transmitted (step 2502). The POS system 95 receives the signed coupon and the device identification information data (step 2504), and transmits a request for requesting verification of the signed coupon to the merchant server 50 (step 2506).

  The verification request message from the POS can include a coupon signature, a coupon ID, and the received device identification information data. The merchant server 50 receives the verification request message (step 2508), decrypts the signature (step 2510), and uses the coupon ID and device identification information data extracted from the signature as the coupon ID and device identification information data received from the POS. (Step 2512). Digital signature is X. When generated using the 509 signing certificate, the merchant server 50 also determines that the coupon is a root X. It can be verified that it was issued by an entity trusted by a 509 agency and thus trusted by a trusted company. If the digital signature is correctly decrypted (this confirms that the issuer can be trusted), and the coupon ID and device identification data retrieved from the signature match those received from the POS system in the verification request message (Ie, determination 2510 = “YES”), merchant server 50 verifies the coupon (step 2514).

  As part of validating the coupon, merchant server 50 also searches for a coupon ID in the coupon database (eg, the invalid coupon object list described below) to determine if the coupon has already been redeemed. The coupon field can be checked to determine if the coupon has expired. If the coupon is verified with a digital signature and the data record indicates that the coupon has not been redeemed and has not expired, the merchant server 50 sends a verification message to the POS system (step 2516). The POS system receives the validation message (step 2518) and applies the coupon to the purchase transaction (step 2520). The POS system optionally sends a coupon usage message to the merchant server 50 to notify the merchant server 50 regarding the use of the coupon (step 2522). The POS system also sends a coupon cancellation message to the mobile device 40 (step 2526). The merchant server 50 receives the coupon usage message (step 2524) and records that the coupon ID has been redeemed. The mobile device 40 receives the cancel message and deletes the coupon from the memory (step 2528).

  If the coupon ID and device identification information data retrieved from the signature do not match that received from the POS (decision 2510 = “NO”), or if the coupon has expired or has been redeemed, the merchant server 50 The coupon is rejected (step 2530) and a reject message is sent to the POS system (step 2532). The POS system receives the reject message and rejects the coupon during the purchase transaction (step 2534).

  FIG. 26 illustrates an implementation method for canceling a digitally signed coupon that was previously redeemed or expired. Upon verifying or rejecting the signed coupon, the merchant server 50 optionally sends a coupon cancellation message to the mobile device 40 to notify the mobile device 40 that the coupon should not be used for other purchase transactions. (Step 2602). The coupon cancellation message can be sent to the mobile device 40 using a unicast network, such as, for example, SMS, email, MMS, or other conventional methods. The mobile device 40 receives the coupon cancellation message (step 2604). As part of receiving the coupon cancellation message, the mobile device 40 may verify the digital signature associated therewith to verify the authenticity of the cancellation message before deleting the corresponding coupon data from memory. it can. This digital signature is used to enable the mobile device 40 to verify that the cancel message has been sent by an authorized authority. 509 signature hierarchy can be used.

  Upon receipt and verification of the coupon cancellation message, the mobile device 40 deletes the coupon stored on the mobile device 40 (step 2605) and acknowledges the deletion or cancellation of the coupon in the mobile device memory with the merchant. It responds to the server 50 (step 2606). Configuring the mobile device to delete or cancel the coupon and send a message confirming the cancellation / deletion of the coupon to the merchant server 50 may result in the merchant and vice versa trying to cash the same coupon multiple times Protect coupon issuers.

  To ensure reliable operation of the coupon delivery and redemption system, the merchant server 50 can determine at decision step 2608 whether a coupon cancellation message acknowledgement has been received. If a coupon cancellation acknowledgment message is received (ie, decision step 2608 = “YES”), the merchant server 50 verifies the coupon and redeems the process (step 2616). However, if a coupon cancellation acknowledgment message has not been received (ie, decision step 2608 = “NO”), merchant server 50 may be maintained by the server or accessed by the server to track redeemed coupons. A “dead coupon object” is created in the possible database (step 2610). The creation of an invalid coupon object in the server accessible database allows the server to recognize the coupon when a previously redeemed coupon is presented to the merchant a second time. Accordingly, as part of the coupon verification process described above with reference to step 2514 in FIG. 25, the merchant server 50 may also determine whether the coupon has been posted as redeemed to determine whether it has been posted. You can check the object database. In one embodiment, the creation of an invalid coupon object can initiate a countdown timer that, when terminated at step 2612, determines whether the coupon is still posted in a database, such as an invalid coupon object database. The merchant server 50 is prompted to do so. If the merchant server 50 is still tracking the redeemed coupon at that time (ie, decision step 2614 = “YES”), the merchant server may send another coupon cancellation message to the mobile device 40. Return to step 2602. If the merchant server 50 is no longer tracking the redeemed coupon (ie, decision step 2614 = “NO”), the merchant server 50 verifies the coupon and the process of redeeming ends (step 2616). Because expired coupons are rejected based on their expiration parameters, the process also ends when the coupon itself expires.

  In one embodiment, the electronic coupon created by merchant server 50 defines whether those coupons can be combined and, if so, the extent to which those coupons can be combined with other coupons. Can include a weight value, which can be used by the merchant. The merchant can establish a rule that the POS system uses to use the assigned coupon weights to determine if some coupon combinations are allowed. The merchant server 50 can implement a rule such that a combination of coupons is not allowed if the total number of weights assigned to the coupons presented to the POS system is greater than a predetermined maximum value. For example, the merchant can assign a weight number of 0.2 to coupon A, a weight number of 0.5 to coupon B, and a weight number of 0.9 to coupon C. The merchant may further implement a rule that when a plurality of coupons are presented to the POS system, if the total number of weights assigned to the coupon is greater than 1, the combination of those coupons is not allowed. Under such rules, the combination of coupon A and coupon B is allowed because the total number of weights assigned to coupon A (0.2) and coupon B (0.5) is less than one. Will. However, under the same rule, the total number of coupon weights assigned to coupon A and coupon B is equal to 1.1 and greater than 1, so the combination of coupon A and coupon C is not allowed. In this example, since the sum of the coupon weights is greater than 1, it is not permitted to combine coupons A, B, and C. This process also allows the merchant system to validate and accept coupons without having to contact the original coupon issuer (s).

  FIG. 27 shows an implementation method for determining whether a combination of a plurality of weighted coupons is allowed. The coupon issuer assigns a weight number to the coupon as part of the coupon issue process (step 2702). During a purchase transaction, a coupon manager (eg, merchant server 50) receives a coupon verification request that includes coupon data for two or more coupons from a POS system (see FIG. 25) (step 2704). The coupon manager calculates the total coupon weight (step 2708) and determines whether the total coupon weight is greater than a predetermined number “n” (decision 2710). If the sum of the weights of two or more coupons is less than or equal to “n” (ie, decision 2710 = “YES”), merchant server 50 verifies the combined use of two or more coupons for a single purchase transaction. (Step 2714). If the sum of the weights of the two coupons is greater than “n” (ie, decision 2710 = “NO”), the merchant server 50 refuses to use a combination of two or more coupons for a single purchase transaction ( Step 2712). Acceptance or rejection of the combined coupon can be communicated to the POS system in a verification or rejection message, similar to that described above with reference to FIG.

  A typical mobile receiver device 40 suitable for use in various embodiments shares the components shown in FIG. For example, the exemplary mobile receiver device 40 may include a processor 191 coupled to an internal memory 192, a display 193, and a speaker 199. Further, mobile receiver device 40 may have an antenna 194 for transmitting and receiving electromagnetic radiation coupled to a wireless data link and / or cellular telephone transceiver 195 coupled to processor 191. In some implementations, the transceiver 195 and the portions of the processor 191 and memory 192 used for cellular telephony are collectively referred to as an air interface because they provide a data interface over a wireless data link. A mobile receiver device generally also includes a keypad 196 or small keyboard and menu selection buttons or rocker switches 197 for receiving user input.

  The processor 191 may be any programmable microprocessor, microcomputer or one or more multiplexes that may be configured by software instructions (applications) to perform various functions, including the functions of the various embodiments described herein. It can be a processor chip. Depending on the mobile device, a plurality of processors 191 can be provided, for example, one processor dedicated to wireless communication functions and one processor dedicated to executing other applications. In general, software applications can be accessed and stored in internal memory 192 before being loaded into processor 191. In some mobile devices, the processor 191 can include internal memory sufficient 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 during electronic parsing, according to various embodiments. In some mobile devices, the secure memory can be in a separate memory chip coupled to the processor 191. In many mobile devices 40, the internal memory 192 can be volatile memory or non-volatile memory (eg, flash memory), or a mixture of both. As used herein, a general reference to memory includes a processor 191 that includes an internal memory 192, a memory chip 190, a removable memory connected to a mobile device, and a memory internal to the processor 191 itself. Refers to all memory accessible by.

  Many of the embodiments described above can also be implemented in any of a variety of remote server devices, such as server 2800 shown in FIG. Such a server 2800 generally includes a processor 2801 coupled to volatile memory 2802 and a large capacity non-volatile memory such as a disk drive 2803. Server 2800 may also include a floppy disk drive and / or a compact disk (CD) drive 2806 coupled to processor 2801. Server 2800 may also include a network access port 2804 coupled to processor 2801 for establishing a data connection with network circuitry 2805, such as the Internet.

  The above method descriptions and process flowcharts are provided merely as illustrative examples and do not require or imply that the steps of the various embodiments must be performed in the order presented. As those skilled in the art will appreciate, the order of the steps in the above embodiments can be performed in any order. Words such as “thereafter”, “then”, “then”, “next” do not limit the order of the steps; these words simply explain the method to the reader Used to guide. Further, reference to an element in a singular claim, for example, using the article “a”, “an” or “the” should not be construed as limiting the element to the singular.

  Various exemplary logic blocks, modules, circuits, and algorithm steps described with respect to the embodiments disclosed herein may be implemented as electronic hardware, computer software, or a combination 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 as hardware or software depends upon the particular application and design constraints imposed on the overall system. Those skilled in the art can implement the described functionality in a variety of ways for each particular application, but such implementation decisions should not be construed as departing from the scope of the invention.

  The hardware used to implement the various exemplary logic, logic blocks, modules, and circuits described with respect to the aspects disclosed herein includes general purpose processors, digital signal processors (DSPs), and application specific integrations. Circuit (ASIC), field programmable gate array (FPGA) or other programmable logic device, individual gate or transistor logic, individual hardware components, or any of them designed to perform the functions described herein Can be implemented or implemented using a combination. 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 be implemented as a combination of computing devices, eg, a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors associated with a DSP core, or any other such configuration. You can also. Alternatively, some steps or methods may be performed by circuitry that is specific to a given function.

  In one or more exemplary aspects, the functions described can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. The steps of the methods or algorithms disclosed herein can be implemented in an executed processor-executable software module that can reside on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that enables transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a computer. By way of example, and not limitation, such computer readable media can be RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage device, or instructions or data structures. Any other medium that can be used to carry or store the desired program code in a form and that can be accessed by a computer can be included. Also, any connection is properly called a computer-readable medium. For example, the software can use a coaxial cable, fiber optic cable, twisted pair, digital subscriber line (DSL), or wireless technology such as infrared, wireless, and microwave, from a website, server, or other remote source When transmitted, coaxial technologies, fiber optic cables, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the media definition. Discs and discs used in this specification are compact discs (CD), laser discs, optical discs, digital versatile discs (DVD), floppy discs. (Disk) and Blu-ray disc (disc), the disc usually reproduces data magnetically, and the disc optically reproduces data with a laser. Combinations of the above should also be included within the scope of computer-readable media. Further, the operation of the method or algorithm may be incorporated into a computer program product as one or any combination or set of codes and / or instructions on a machine readable medium and / or computer readable medium. Can be resident.

  The above 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 following claims and the principles and novel features disclosed herein. It is.

Claims (75)

In a method for delivering electronic coupons via a mobile broadcast TV system,
Broadcasting a coupon template containing coupon access information from a mobile broadcast TV service provider to a receiver device;
Receiving device identification information data from the receiver device;
Creating a digitally signed coupon including a digital signature based on the device identification information data received from the receiver device;
Sending the digitally signed coupon to the receiver device via a unicast network;
Storing the digitally signed coupon in a memory of the receiver device.   The method of claim 1, wherein the coupon template access information is selected from a group consisting of a URL and a telephone number.   The device identification information data is one or more 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. The method of claim 1 comprising an item.   The method of claim 1, wherein the device identification information data can be received via the Internet.   The method of claim 1, wherein the device identification information data may be received via the unicast network.   The method of claim 1, wherein the digital signature of the coupon is generated for a coupon ID and receiver device identification information.   The digital signature of the coupon is root X. X. 509 The method of claim 1, wherein the method is generated using a chain of 509 certificates.   The method of claim 1, further comprising: providing coupon data and the digital signature from the receiver device to a point-of-sale system in a coupon redemption transaction.   9. The method of claim 8, further comprising validating the coupon data based on the coupon data and the digital signature at the point-of-sale system. A coupon verification request requesting verification of the validity of the digitally signed coupon (the verification request is accompanied by the digitally signed coupon, actual receiver device identification information, and coupon ID data) from the point of sale system. Sending to the verification system;
Receiving the coupon verification request in the coupon verification system;
Decrypting the digital signature of the digitally signed coupon received with the verification request;
Determining whether the receiver device identification information and coupon ID data retrieved from the digital signature match the receiver device identification information and coupon ID data;
If the receiver device identification information and coupon ID data retrieved from the digital signature match the actual receiver device identification information and coupon ID data, a coupon verification message for verifying the digitally signed coupon is sent to the point of view. 9. The method of claim 8, further comprising transmitting to a sale system. Sending a coupon cancellation message from the point-of-sale system to the receiver device;
11. The method of claim 10, further comprising deleting the digitally signed coupon from a memory of the receiver device in response to receiving the coupon cancellation message.   Decrypting the digital signature includes root X. X. 509 The method of claim 10, wherein the method is accomplished using a chain of 509 certificates. In a system for distributing electronic coupons via a mobile broadcast TV system,
A mobile broadcast TV network system,
A broadcast transmitter and a server, the server comprising:
Broadcasting a coupon template containing coupon access information to the broadcast transmitter;
Receiving device identification data from the receiver device;
Creating a digitally signed coupon including a digital signature based on the device identification information data received from the receiver device;
A mobile broadcast TV network configured with server executable instructions configured to cause the server to perform an operation comprising transmitting the digitally signed coupon to the receiver device via a unicast network System,
A receiver device configured to receive a mobile broadcast TV transmission comprising:
Processor,
A memory coupled to the processor; and
A receiver device coupled to the processor and configured to receive a mobile broadcast TV transmission, the processor comprising:
Receiving the broadcast coupon template including coupon access information;
Transmitting device identification information data to the server based on the coupon template access information;
Receiving the digitally signed coupon from the server via the unicast network;
A receiver device configured with processor-executable instructions for performing an operation comprising storing the digitally signed coupon in the memory.   14. The system of claim 13, wherein the coupon template access information is selected from a group consisting of a URL and a telephone number.   The device identification information data is one or more 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. 14. The system of claim 13, comprising an item.   The system of claim 13, wherein the processor is configured with processor executable instructions such that the device identification information data is transmitted to the server over the Internet.   14. The system of claim 13, wherein the processor is configured with processor-executable instructions such that the device identification information data is transmitted to the server over the unicast network.   The server is configured with server executable instructions configured to perform an operation further comprising generating the digital signature of the coupon against a coupon ID and receiver device identification information. System.   The server may generate the digital signature of the coupon as root X. X. 509 The system of claim 18 configured with server executable instructions to include generating the digital signature using a chain of 509 certificates. Further includes a point-of-sale system,
The processor is configured with processor-executable instructions for performing operations further comprising providing coupon data and the digital signature from the receiver device to the point-of-sale system in a coupon redemption transaction. Item 13. The system according to item 13.   21. The system of claim 20, wherein the point-of-sale system is configured to verify the coupon data based on the coupon data and the digital signature. Receiving a coupon verification request requesting verification of the validity of the digitally signed coupon from the point-of-sale system (the verification request includes the digitally signed coupon and the actual receiver device identification information and coupon ID; With data)
Decrypting the electronic signature of the digitally signed coupon received with the verification request;
Determining whether the receiver device identification information and coupon ID data retrieved from the electronic signature match the receiver device identification information and coupon ID data;
If the receiver device identification information and coupon ID data retrieved from the electronic signature matches the actual receiver device identification information and coupon ID data, a coupon verification message for verifying the digitally signed coupon is sent to the point of view. 21. The system of claim 20, further comprising a coupon verification server configured with server-executable instructions to perform operations including transmitting to a sale system. The point-of-sale system is further configured to send a coupon cancellation message to the receiver device;
The processor is configured with processor executable instructions to perform an operation further comprising deleting the digitally signed coupon from the memory of the receiver device in response to receiving the coupon cancellation message. 23. The system of claim 22, wherein:   The coupon verification server decrypts the electronic signature using a route X. X. 509 23. The system of claim 22, configured with server executable instructions to include decrypting the electronic signature using a chain of 509 certificates. A system for distributing electronic coupons via a mobile broadcast TV system,
Means for broadcasting a coupon template containing coupon access information from a broadcast service provider to a receiver device;
Means for receiving device identification information data from the receiver device;
Means for creating a digitally signed coupon including a digital signature based on the device identification information data received from the receiver device;
Means for transmitting the digitally signed coupon to the receiver device over a unicast network;
Means for storing the digitally signed coupon in a memory of the receiver device.   26. The system of claim 25, wherein the coupon template access information is selected from a group consisting of a URL and a telephone number.   The device identification information data is one or more 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. 26. The system of claim 25, comprising an item.   26. The system of claim 25, wherein the device identification information data can be received via the Internet.   26. The system of claim 25, wherein the device identification information data can be received via the unicast network.   26. The system of claim 25, further comprising means for generating the digital signature of the coupon for a coupon ID and receiver device identification information.   The means for generating the digital signature of the coupon is root X. X. 509 32. The system of claim 30, including means for generating the digital signature using a chain of 509 certificates.   26. The system of claim 25, further comprising means for providing coupon data and the digital signature from the receiver device to a point-of-sale system in a coupon redemption transaction.   The system of claim 32, further comprising means for verifying the coupon data based on the coupon data and the digital signature at the point-of-sale system. Means for sending a coupon verification request from the point-of-sale system to the coupon verification system requesting verification of the validity of the digitally signed coupon (the verification request includes the digitally signed coupon, the actual receiver device identification Information and coupon ID data)
Means for receiving the coupon verification request in the coupon verification system;
Means for decrypting the electronic signature of the digitally signed coupon received with the verification request;
Means for determining whether the receiver device identification information and coupon ID data retrieved from the electronic signature match the receiver device identification information and coupon ID data;
If the receiver device identification information and coupon ID data retrieved from the electronic signature matches the actual receiver device identification information and coupon ID data, a coupon verification message for verifying the digitally signed coupon is sent to the point of view. 33. The system of claim 32, further comprising means for transmitting to the sale system. Means for sending a coupon cancellation message from the point-of-sale system to the receiver device;
35. The system of claim 34, further comprising: means for deleting the digitally signed coupon from a memory of the receiver device in response to receiving the coupon cancellation message.   The means for decrypting the electronic signature includes root X. X. 509 35. The system of claim 34, comprising means for decrypting the electronic signature using a chain of 509 certificates. A receiver device,
A processor;
A memory coupled to the processor;
A receiver circuit coupled to the processor and configured to receive a mobile broadcast TV transmission;
The processor is
Receiving a coupon template including coupon access information in a mobile broadcast TV transmission;
Establishing a communication link with a server based on the coupon access information;
Sending device identification information data relating to the receiver device to the server;
Receiving a digitally signed coupon including a digital signature;
A receiver device configured with processor-executable instructions for performing an operation comprising storing the digitally signed coupon in a memory of the receiver device.   38. The receiver device of claim 37, wherein the coupon template access information is selected from a group consisting of a URL and a telephone number.   The device identification information data is one or more 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. 38. The receiver device of claim 37, comprising an item.   38. The receiver device of claim 37, wherein the processor is configured with processor-executable instructions such that the communication link with the server and the device identification information data are transmitted to the server over the Internet.   38. The receiver device of claim 37, wherein the processor is configured with processor executable instructions so that the communication link with the server and the device identification information data are transmitted to the server over a unicast network. .   The processor is configured with processor-executable instructions to perform operations further comprising verifying the digital signature, and if the digital signature is verified, the digitally signed coupon is stored in memory. 38. The receiver device of claim 37.   The processor is configured such that the digital signature is root X. X. 509 43. The receiver device of claim 42, configured with processor executable instructions to be verified using a chain of 509 certificates.   38. The receiver device of claim 37, wherein the processor is configured with processor-executable instructions to perform operations further comprising providing coupon data and the digital signature to a point-of-sale system in a coupon redemption transaction. . The processor is
Receiving a coupon cancellation message from the point of sale system;
45. The receiver device of claim 44, configured with processor-executable instructions to perform an operation further comprising deleting the coupon from memory in response to receiving the coupon cancellation message. Means for receiving a coupon template including coupon access information in a mobile broadcast TV transmission;
Means for establishing a communication link with a server based on the coupon access information;
Means for transmitting device identification information data relating to the receiver device to the server;
Means for receiving a digitally signed coupon including a digital signature;
Means for storing the digitally signed coupon in the receiver device.   47. The receiver device of claim 46, wherein the coupon template access information is selected from a group consisting of a URL and a telephone number.   The device identification information data is one or more 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. 49. The receiver device of claim 46, comprising an item. Means for establishing a communication link with said server includes means for establishing an internet communication link;
47. The receiver device of claim 46, wherein means for transmitting the device identification information data to the server includes means for transmitting the device identification information data to the server via the established internet communication link. The means for establishing a communication link with the server includes means for establishing a unicast communication link;
47. The receiver device of claim 46, wherein means for transmitting the device identification information data to the server includes means for transmitting the device identification information data to the server over the established unicast communication link. .   47. The receiver device of claim 46, further comprising means for verifying the digital signature, wherein the digitally signed coupon is stored in memory if the digital signature is verified.   The means for verifying the digital signature includes root X. X. 509 52. The receiver device of claim 51, comprising means for verifying the digital signature using a chain of 509 certificates.   49. The receiver device of claim 46, further comprising means for providing coupon data and the digital signature to a point-of-sale system in a coupon redemption transaction. Means for receiving a coupon cancellation message from the point of sale system;
54. The receiver device of claim 53, further comprising means for deleting the coupon from 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 including coupon access information in a mobile broadcast TV transmission;
Establishing a communication link with a server based on the coupon access information;
Sending device identification information data relating to the receiver device to the server;
Receiving a digitally signed coupon including a digital signature;
A processor-readable storage medium storing processor-executable instructions configured to perform an operation comprising storing the digitally signed coupon in a memory of the receiver device.   56. The processor readable storage medium of claim 55, wherein the coupon template access information is selected from the group consisting of a URL and a telephone number.   The device identification information data is one or more 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 processor readable storage medium of claim 55, comprising items. Establishing a communication link with the server includes establishing an internet communication link;
56. The processor-readable storage medium of claim 55, wherein transmitting the device identification information data to the server includes transmitting the device identification information data to the server via the established Internet communication link. Establishing a communication link with the server includes establishing a unicast communication link;
56. The processor-readable storage medium of claim 55, wherein transmitting the device identification information data to the server includes transmitting the device identification information data to the server via the established unicast communication link.   The stored processor executable instructions are configured to cause a processor to perform an operation further comprising verifying the digital signature, and storing the digitally signed coupon in memory when the digital signature is verified. 56. The processor readable storage medium of claim 55, wherein:   Verifying the digital signature includes root X. X. 509 61. The processor readable storage medium of claim 60, comprising verifying the digital signature using a chain of 509 certificates.   56. The processor-readable storage medium of claim 55, further comprising providing coupon data and the digital signature to a point-of-sale system in a coupon redemption transaction. The stored processor executable instructions are:
Receiving a coupon cancellation message from the point of sale system;
64. The processor-readable storage medium of claim 62, configured to cause the processor to perform an operation further comprising deleting the coupon from memory in response to receiving the coupon cancellation message. A method for providing an electronic coupon to a receiver device via a mobile broadcast TV system, comprising:
Broadcasting a digitally signed coupon including coupon data and a digital signature from a mobile broadcast TV network;
Receiving the broadcast digitally signed coupon at a receiver device;
Decrypting the digital signature using a decryption key;
Obtaining receiver device identification information data included in the digital signature;
Determining whether the obtained receiver device identification information data matches the identification information data of the receiver device;
Storing the digitally signed coupon in the memory of the receiver device when there is a match between the retrieved device identification information data and receiver device identification information data.   Decrypting the digital signature includes root X. X. 509 68. The method of claim 64, wherein the method is accomplished using a chain of 509 certificates. A processor;
A memory coupled to the processor;
A receiver circuit coupled to the processor and configured to receive a mobile broadcast TV transmission;
The processor is
Receiving a digitally signed coupon including coupon data and a digital signature from a mobile broadcast TV network;
Decrypting the electronic signature using a decryption key;
Obtaining receiver device identification information data included in the digital signature;
Determining whether the obtained receiver device identification information data matches the identification information data of the receiver device;
Processor-executable instructions for performing operations including storing the digitally signed coupon in the memory when there is a match between the retrieved device identification data and receiver device identification data Receiver device configured with.   Decrypting the electronic signature includes root X. X. 509 68. The receiver device of claim 66, wherein the processor is configured with processor executable instructions, as achieved using a chain of 509 certificates. Means for receiving a digitally signed coupon comprising coupon data and a digital signature from a mobile broadcast TV network;
Means for decrypting the electronic signature using a decryption key;
Means for obtaining receiver device identification information data included in the digital signature;
Means for determining whether the obtained receiver device identification information data matches the identification information data of the receiver device;
A receiver device comprising: means for storing the digitally signed coupon when there is a match between the retrieved device identification data and the receiver device identification data.   Means for decrypting the electronic signature using a decryption key include root X. X. 509 69. The receiver device of claim 68, comprising means for decrypting the electronic signature using a chain of 509 certificates. A processor of a receiver device capable of receiving mobile broadcast TV transmissions;
Receiving a digitally signed coupon including coupon data and a digital signature from a mobile broadcast TV network;
Decrypting the electronic signature using a decryption key;
Obtaining receiver device identification information data included in the digital signature;
Determining whether the obtained receiver device identification information data matches the identification information data of the receiver device;
Processor-executable instructions configured to cause an operation comprising storing the digitally signed coupon when there is a match between the retrieved device identification data and receiver device identification data. Stored processor-readable storage medium.   Decrypting the electronic signature using a decryption key is a root X. X. 509 The processor-readable storage medium of claim 70, comprising decrypting the electronic signature using a chain of 509 certificates. A method for verifying a combination of a plurality of coupons,
Receiving a request to combine multiple coupons with weight numbers for a single purchase transaction;
Calculating the sum of the weight numbers of the plurality of coupons;
Determining whether the sum of the weight numbers of the plurality of coupons exceeds a predetermined number;
Verifying the combined use of the plurality of coupons if the sum of the weight numbers does not exceed the predetermined number. A computer for verifying a combination of a plurality of electronic coupons presented for exchange,
Receiving a request to combine multiple coupons with weight numbers for a single purchase transaction;
Calculating the sum of the weight numbers of the plurality of coupons;
Determining whether the sum of the weight numbers of the plurality of coupons exceeds a predetermined number;
Including a processor configured with processor-executable instructions to perform operations including verifying the combined use of the plurality of coupons if the sum of the weight numbers does not exceed the predetermined number. Computer. A system for verifying a combination of a plurality of coupons presented for exchange,
Means for receiving a request to combine multiple coupons with weights for a single purchase transaction;
Means for calculating a sum of the weight numbers of the plurality of coupons;
Means for determining whether the sum of the weight numbers of the plurality of coupons exceeds a predetermined number;
Means for verifying the combined use of the plurality of coupons if the sum of the weight numbers does not exceed the predetermined number. Receiving a request to combine multiple coupons with weight numbers for a single purchase transaction;
Calculating the sum of the weight numbers of the plurality of coupons;
Determining whether the sum of the weight numbers of the plurality of coupons exceeds a predetermined number;
A computer storing computer-executable instructions configured to cause a computer to perform an operation including verifying the combined use of the plurality of coupons if the sum of the weight numbers does not exceed the predetermined number A readable storage medium.

Images