KR101278369B1 - System and method for dynamic pricing of mobile tv content - Google Patents

Abstract

The method and system allow mobile TV broadcast service providers to allow dynamic pricing for access to broadcast programs. A server in the mobile TV broadcast network may negotiate a price for accessing the broadcast program with each user through the mobile device. The server may receive a request to access a broadcast program with a price offer from a mobile device. The server may respond to the price offer by accepting the price offer or by making a counter offer until mutually acceptable prices are identified. Alternatively, the server may implement any of a number of types of auctions for access to the broadcast program. Similar to the negotiable dynamic pricing method, once the purchase request for viewing access to the broadcast content program is accepted at the current quote price, the mobile TV broadcast service provider may provide a decryption key suitable for the users whose offer or bid has been accepted. You can also send.

Description

SYSTEM AND METHOD FOR DYNAMIC PRICING OF MOBILE TV CONTENT}

Related application

This application claims priority to US Provisional Application No. 61 / 086,748, filed August 6, 2008, entitled "System and Method for Negotiating Price of Mobile TV Content," which is hereby incorporated by reference in its entirety. Included as.

Wireless communication technology has seen explosive growth in the past few years. This growth is fueled by wireless services that provide the mobile public with freedom of movement and remove the tethers to hardwired communication systems. In addition, the increasing quality and speed of voice and data communications over wireless media are attracting additional users. As a result of these service enhancements, the popularity of wireless services is expected to continue to grow rapidly.

Recently, wireless communication technology also has the ability to broadcast programs to mobile users. Mobile broadcast users can use their cell phones or other wireless devices to view mobile editions of news, entertainment, sports, business, and other programming. These broadcast systems are increasing significantly in worldwide use and utility. Currently, mobile TV broadcast service providers set static prices for viewing access to broadcast content programs. Users choose to subscribe or not to subscribe to a broadcast content program based on a static price for viewing access.

Various embodiments herein provide methods and systems that allow mobile TV broadcast service providers to maximize revenue generating opportunities by dynamically pricing viewing access to broadcast content programs. In one embodiment, a mobile TV broadcast service provider may negotiate viewing access fees with an individual mobile device via a server. The server of the mobile TV broadcast service provider may request a static fee for viewing access to the broadcast content. After a predetermined time has elapsed, the server may broadcast a dynamic pricing message to the plurality of mobile devices indicating that viewing access to the broadcast program is available via dynamic pricing. The server may then receive a dynamic price offer from an individual mobile device and negotiate with the mobile device until mutually agreeable rates are identified. Once the mobile device and server agree to each other for a fee for viewing access, the server sends (or instructs the transmission) to send the user an appropriate decryption key that will provide the mobile device with sufficient viewing access to complete the viewing for the desired program. ) You may. In another alternative embodiment, the server of the mobile TV broadcast service provider may offer various auctions that may attract additional mobile devices to subscribe to the broadcast content by providing multiple price points at which different users may be willing to subscribe to the broadcast content program. It may work.

The accompanying drawings, which are incorporated herein and constitute a part of this specification, illustrate exemplary embodiments of the invention and, together with the general description provided above and the detailed description provided below, serve to explain the features of the invention.
1 is a block diagram illustrating a mobile TV broadcasting communication system.
2 is a block diagram of a mobile TV broadcasting system.
3 is a flowchart of a price negotiation method of an embodiment.
4 is a flow diagram and method for setting up a content manager server for approval of dynamic pricing.
5 is a flowchart of a broadcast content price negotiation method.
6 is a flowchart performed by a mobile TV broadcast system of a method for transmitting a suitable decryption key to a user's mobile device to allow viewing access to a broadcast content program.
7 is a flowchart of a method for transmitting a suitable decryption key to a user's mobile device to allow viewing access to a broadcast content program.
8 is a flowchart illustrating interaction of broadcast system elements.
9 is an illustration of a service guide data model.
10 is a flowchart of a dynamic pricing method for broadcast content.
11 is a flowchart of a dynamic pricing method for broadcast content.
12 is a flowchart of a dynamic pricing method for broadcast content.
13 is a block diagram of a mobile device.
14 is a block diagram of a server device.

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

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

As used herein, the terms “mobile device” refer to cellular telephones, personal data assistants, palm-top computers, laptop computers, wireless electronic mail receivers (eg, Blackberry® and Treo® devices), multimedia Internet-enabled cellular telephones (eg, Blackberry Storm®), global positioning system (GPS) receivers, wireless game controllers, and programmable processor and memory and mobile TV broadcast transmissions. It refers to any one or all of similar personal electronic devices including mobile TV broadcast receiver circuitry for processing.

The word "broadcast" is used herein to mean the transmission of information (information packets) that allows data to be received simultaneously by multiple receiving devices. Examples of broadcast messages are traditional paper network, mobile television service broadcast signals, including overhead information broadcasts (overhead flows) such as content broadcasts (content flows) and metadata messages. The term "unicast network" is used herein to refer to communication networks that transmit data to a single destination. Examples of unicast networks include Wi-Fi (WiFi) and cellular data communication networks. Examples of unicast transmissions include simple message service (SMS), multimedia message service (MMS), and e-mail messages that may be carried over a cellular telephone data communication network.

The term "content providers" is used herein to refer to companies that provide video, audio, text, graphics, multimedia, websites, and other data that is broadcast through mobile television systems. The term "mobile TV broadcast service providers" is used herein to refer to entities that broadcast mobile television signals. Typically, mobile TV broadcast service providers receive broadcast content from content providers and deliver it to users via a broadcast network.

The growing popularity of mobile television (TV) is providing new sources of revenue for content providers and mobile TV broadcast service providers that can reach additional consumers using new media. The new revenue model includes subscription-based sales of mobile television access, Pay-per-view (PPV) or Pay-per-time (PPT) mobile television access. For example, mobile TV broadcast service providers subscribe to users for viewing access to individual broadcast content programs or to a bundled package of multiple broadcast content programs (eg, professional football pass). You can generate revenue from their services by selling them. By individually encrypting broadcast content programs and providing users with the necessary decryption keys only when payments for subscription can be received or otherwise committed, mobile TV broadcasters can access which viewers have access to specific broadcast content programs. It can be controlled whether to obtain. In conventional systems, the price charged for each subscription is static. The static price may be chosen to attract the most potential subscribers while allowing mobile TV broadcast service providers to recover fixed costs associated with some profits as well as the broadcast of the program. Choosing a suitable static price may be difficult because the pool of potential subscribers is likely to have varying degrees of interest in the broadcast content program.

The degree of interest of each potential subscriber may have in the broadcast content program, so the price each potential subscriber may be willing to pay for viewing access to the broadcast content program may vary as a function of time to the actual broadcast. For example, a mobile TV broadcast service provider may begin advertising viewing access to sporting events prior to actual events and broadcasts. A few weeks before the event, there may be little interest in the event. As a result, a relatively low static price may be chosen to attract as many subscribers as possible. However, as advertisements around the live event are built, the interest seen in the event may be a peak just before the broadcast. Also, the more dynamic an event is, the more interested it is in an event that might exceed expectations (e.g., a sporting event where background stories from participants are increasing the interest of the event), and thus a pay-per that will maximize profits. It causes difficulty in setting the view price.

Certain broadcast content programs may be considered perishable food. For example, a live sporting event may be considered expensive content before broadcasting if the results are unknown. Many potential subscribers may be willing to pay a premium to subscribe to being able to record or view events occurring in real time. However, as the sporting event progresses, the result will be less uncertain and its value for potential subscribers will decrease. Regardless of the number of subscribers, the broadcast will consume a fixed amount of mobile TV broadcast service provider resources (server storage and processing, OA & M and billing, radio link bandwidth, etc.) while the content has the most expensive value ( That is, any viewing access subscriptions that are not sold before the broadcast represent a lost revenue opportunity.

In some circumstances, a broadcast network may be treated like an accessory of a stadium venue. In this situation, the number of "seats" for broadcast viewing may be limited as at stadiums because of contracts with event organizers. In this scenario, traditional methods (eg, Dutch Auction) may be used to obtain the best selling price for a limited number of seats.

For this reason, it would be advantageous for mobile TV broadcast service providers to implement some form of dynamic pricing for viewing access to at least some of its broadcast content programs. Dynamic pricing methods may allow mobile TV broadcasters to maximize revenue generating some programming opportunities by allowing the market to influence the pricing that is suitable for viewing access to broadcast content programs. It may be.

Dynamic pricing may be implemented, for example, by allowing a user to negotiate a price for viewing access with a mobile TV broadcast service provider. In this way, a mobile TV broadcast service provider may appeal to various subscribers to maximize the number of subscribers to a particular program and the level of interest for their respective changing program. In addition, the mobile TV provider may maximize the price received for viewing access by allowing subscribers with the least interest to pay more while still attracting subscribers. Potential subscribers may be allowed to suggest a price at which they are willing to pay for viewing access to the broadcast content program. The mobile TV broadcast service provider may then accept or reject this offer. In addition, the mobile TV broadcast service provider may be configured to provide a counter offer.

Currently, the OMA Open Mobile Alliance Broadcast Working Group (BCAST) specification defines a standardized set of service provision messages (eg, for subscription / unsubscription, pricing research, account information retrieval, etc.). In addition, the OMA BCAST Service Guide (SG) specification indicates when a price associated with a particular broadcast content is not in the "purchase data" portion of the guide, which means that the purchase price of the broadcast content is negotiable with the user in future purchase transactions. do. Various embodiments disclosed herein provide a system and method for supporting a dynamic pricing model for broadcasting mobile TV content, such as negotiable pricing schemes.

The price negotiation method does not necessarily mean a price reduction, but may also allow the approved price to be higher than the initial price. This may be implemented, for example, after the nominal purchase time window expires, giving potential subscribers the opportunity to subscribe to broadcast content at the last minute. In this way, the mobile TV broadcaster may charge a "late" fee associated with the broadcast content beyond the normal purchase cycle. This last minute rate increase may be justified because the last minute purchase can increase the costs associated with OA & M and billing resources. Alternatively, in some cases, the last minute purchase may not be accepted because extreme demands may cause the wireless interface itself to become a bottleneck for making a subscription request. This pricing model may also be advertised as offering an undiscounted price to early buyers.

Other dynamic pricing may also be implemented. For example, mobile TV broadcast service providers may implement an auction that allows a user to submit bids indicating that users are willing to pay for viewing access. Different variations of auctions may be implemented, which may allow a mobile TV broadcaster to attract the maximum number of subscribers while allowing users to pay according to the relative level of interest for a particular program.

Many different mobile TV layer technologies and related standards are available or contemplated in the future, all of which may implement and benefit from various embodiments. Such standards include OMA BCAST (Open Mobile Alliance Mobile Broadcast Services Enabler Suite), MediaFLO, Digital Video Broadcast IP Datacasting (DVB-IPDC), and China Multimedia Mobile Broadcasting (CMMB). While broadcast formats and terms may vary between different mobile TV service standards, they all use metadata transmissions to cause the mobile device to receive selected content and to inform users of the programs and content available for viewing or downloading. . In order to avoid confusion regarding particular broadcast standards, generic terminology content flows, overhead flows, and metadata messages are used herein to describe various embodiments.

Typically, mobile TV broadcast transmissions are encrypted so that access to programming can be sold based on subscription, pay-per-play or pay-per-view. Thus, when various embodiments allow the user and the mobile TV broadcast service provider to mutually agree on a price for a particular broadcast content, an decryption key may be sent to the user's mobile device to enable viewing. Typically, mobile TV broadcast services use a unicast communication network, such as a consumer's cellular telephone data service, to communicate subscription messages to / from a particular consumer mobile device, and separate to broadcast mobile television programming to all mobile devices. Use broadcast network. In summary, a mobile TV broadcast service provider may transmit a message that includes information that causes the mobile device to generate a decryption key needed to receive a particular broadcast. The decryption key may be configured to expire after a predetermined amount of time to enable pay-per-view type service, as well as to limit the economic impact of the decryption key falling into the public domain. The message providing the decryption key may also include service restriction parameters that may be used to limit the received broadcast services to a particular program, channel, or other market segment.

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

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

In a conventional mobile TV broadcast system, users subscribe to a mobile TV broadcast service provider for viewing access to specific broadcast content and pay a static price for viewing access. Once the payment for the subscription is verified, the mobile TV broadcast service provider sends the LTKM or STKM to allow the user with access to view the program. Typically, the static price of viewing access is listed in a service guide that indicates other information about the broadcast content (eg, channel, time, duration, etc.).

The mobile TV broadcast service allows the mobile device to be separated from some of the broadcast transmissions carrying content (referred herein as "content flow") (referred herein as "overhead flow" or "content description flow"). Independence by broadcasting information about programs and content to be broadcasted in the future through some of the dedicated broadcast transmissions for carrying overhead information. The mobile device can also process this metadata to provide the electronic viewing guide to the user. Such electronic viewing guides, known in several mobile TV formats such as "Service Guide" (SG) or "Electronic Service Guide" (ESG), are viewable program guides similar to those available on cable and satellite television systems. Typically, these service guides include fixed pricing information that informs potential subscribers (also referred to as users) of the cost of viewing the broadcast content.

Content metadata referred to herein as a “service guide” may be transmitted in an overhead flow that occupies a low bandwidth portion of a mobile TV broadcast signal for carrying overhead information such as program and content metadata. In contrast to this overhead flow, programs and content are broadcast using the high bandwidth portions of the broadcast signal, commonly referred to herein collectively as the "content flow."

Example components of a typical mobile TV broadcast system 100 are shown in FIG. 1. Typically, the mobile TV broadcast network 1 comprises a plurality of broadcast transmitters 2 controlled by the mobile broadcast network control center 4. The mobile TV broadcast network 1 broadcasts content from broadcast transmitters 2 such as mobile broadcast transmissions 3 for reception by the mobile device 10. Within the mobile broadcast network control center 4, there are typically broadcast metadata messages through scheduling of content broadcasts, generation of electronic service guides and other metadata relating to content broadcasts, and overhead flow of the mobile TV broadcast network 1; There is one or more content manager servers 6 that may be configured to manage the creation of. One or more content manager servers 6 may also include a connection to an external network, such as the Internet 7, via which the content manager server 6 feeds content from the content provider server 8. You can also listen. One or more content manager servers 6 may be configured in accordance with various embodiments to receive content from content provider server 8 and to determine information about received content, such as a fixed fee for viewing access to defense content. It may be. In addition, the content manager server 6 may take charge of receiving a broadcast content program request. Such a request may be made by the user in association with either a static pricing model or a dynamic pricing model. 1 shows a content manager server 6 that performs the functions of subscription management as well as content management, in other embodiments, multiple servers may be used to perform these functions. Thus, in these other embodiments, additional subscription manager servers (not shown) may be provided in association with the content manager server 6. The content manager server 6 may take on the task of performing all content management functions, while the subscription manager server may take on the task of receiving content program requests. Such a request may be made by the user in connection with either a static pricing model or a dynamic pricing model.

In order to allow a user to request a broadcast program, the mobile device 10 may communicate with the content manager server 6 via the unicast network 5. Alternatively, mobile device 10 may communicate with content manager 6 via unicast network 5 and the Internet 7. For example, when the user is located outside the user's home network and the user's home network subscription manager is not available, a need may arise for communicating with the content manager 6 via the unicast network and the Internet 7. When the viewing request is accepted, the content manager server 6 may use another billing server (not shown) to facilitate proper billing of each account to complete the process for allowing viewing access to the broadcast content program. It can also communicate with.

Referring to FIG. 2, the viewing request may also be made from the secondary user terminal 11. For example, a user may want to schedule viewing of a program on mobile device 10 from a remote computer logged into the user's account. The user may use the secondary user terminal to communicate with the program bidding manager 9 via the Internet 7. Once the price negotiation is successfully completed and the viewing request is accepted, the program bid manager 9 may instruct the subscription management center 12 to send the cryptographic key necessary for the actual viewing to the mobile device 10.

Typically, mobile TV broadcast service providers receive a variety of different programs and content from different content sources and content providers. Mobile TV broadcast service providers typically store content on a server, schedule a broadcast window for each content, and then broadcast the content in batches. In order for the mobile device to receive the content, the mobile TV broadcast service provider server may send a meta for transmission via an overhead flow informing the mobile device when each program or content is to be transmitted and the broadcast address to which the transmission is to be made. Will generate a data message. In the case of a live television event (eg, sporting event, concert), the content is transcoded before broadcasting via streaming. This may result in small latency due to transcoding. Typically, since a mobile TV broadcast service provider may be well known ahead of a live television event when a live event occurs, the mobile TV broadcast service provider may determine when each program or content will be transmitted and the broadcast address to which the transmission will be made. It may still generate a metadata message for transmission via an overhead flow informing the. The mobile device can use the information in the metadata message to determine if any content has been selected by the user for stream reception and file download, in which case watching the network address and broadcast transmission for the selected content to be received ( Determine the time for tune in.

2 shows an information flow diagram 200 illustrating a message and information flow in a mobile TV broadcast network 1 according to one embodiment. As mentioned above, the mobile TV broadcast network 1 may receive content (eg, television program website, serial data feed, etc.) from multiple content sources 8a, 8b. Such content may be provided to the content manager server 6 in the mobile TV broadcast network 1 via the data network 20 (eg, the Internet 7 of FIG. 1). The content manager server 6 may store such content in a database and schedule broadcast content. In the scheduling of broadcast content, the content manager server 6 determines when and on what network address to be broadcast. As part of the scheduling, the content manager server 6 may format the content into a content package (CP). The content manager server 6 may also include the title of the information, its source (eg, internet address, URL or producer), the nature of the information (eg, sports, news, finance, etc.), its age or creation date. Information about the content, such as / time, and pricing of viewing access to the content. The content manager server 6 may combine the scheduled broadcast time and address with other information about the content to generate a content packet description (CPD) in the form of a service guide. When content is scheduled for broadcast, the content manager server 6 may provide the content package to the content broadcast system 4 in the network data flow 22. The service guide may be provided in a network data flow 24. These data flows are then processed by the content broadcast system 4 into multiplex broadcast waveforms that are broadcast live by the network transmitter 2, such as broadcast transmission.

Within a broadcast transmission, there may be several different content flows (CFs) 26 that are data packets carrying broadcast content in addition to a service guide flow 28 that includes data packets carrying content packet descriptions. Mobile device 10 can receive the broadcast transmission and process content flow (s) 26 and service guide flow 28 separately.

To facilitate dynamic pricing, each user's mobile device 10 may communicate with the program response manager 9 via the unicast network 5. The program response manager 9 may be a software module operating in the content manager server 6 or may be software operating on a separate server in direct communication with the content manager server 6. The program bid manager 9 module in the content manager server 6 is capable of sending dynamic price offers, acceptances and counter offers to each individual mobile device 10 and receiving dynamic price offers, acceptances and counter offers from mobile devices. You may be responsible for that.

The communication between the program bid manager 9 module and the mobile device 10 may be via a bidirectional communication link on the unicast network 5. The bidirectional communication link may be configured to communicate voice traffic and / or data traffic between various devices including each of the mobile devices 10. Bidirectional links as used by various embodiments are not limited to wireless links or even specific telephony technologies, and include one or more of Ethernet, telephone (eg, POTS), cables, power lines, and fiber optic systems. One or more wired and / or wireless links, and / or code division multiple access (CDMA or CDMA 2000) communication systems, frequency division multiple access (FDMA) systems, GSM / GPRS (General Packet Radio Service) / EDGE (enhanced data GSM) time division multiple access (TDMA) systems, such as Terrestrial Trunked Radio (TETRA) mobile telephone systems, wideband code division multiple access (WCDMA) systems, and high data rate (1xEV-DO or! xEV-DO gold multicast) systems A wireless system including one or more of an IEEE 802.11 system, or an orthogonal frequency division multiple access (OFDM) based system.

In operation, the service guide is generated by the content manager server 6 in the mobile TV broadcast network 1. The service guide includes data models that model services, schedules, content, related purchase and supply data, access and interactive data using fragments. The service guide may be as defined in the OMATS-BCAST_Services-V1_0 specification from the OMA.

3 is an overview process flow diagram illustrating an embodiment method 300 for dynamic price negotiation. The price negotiation process may be performed by a content manager server 6 having a program response manager 9 operating as a module in the content manager server 6 or as a separate server in communication with the content manager server 6. For brevity, the program bid manager 9 will be described as a module in the content manager server 6. The operation of the program response manager 9 will be referred to as being performed by the content manager server 6. However, these operations may be performed by different servers within or connected to the mobile TV broadcast system.

When the service guide is received, the user may determine that the user is interested in watching a particular broadcast content program. In the dynamic pricing operation, at step 50, the content manager server 6 may receive a user dynamic pricing offer for the broadcast program. The content manager server 6 may evaluate the user's price offer and determine whether the price offer is acceptable at decision 51. This may be achieved, for example, by comparing the proposed price with a predetermined threshold stored in memory, or by analyzing the proposed price using an algorithm to predict the maximum profit price. If the price offer is acceptable (ie, decision 51 = yes), the content manager server 6 may initiate a process to send a message to the user that the price offer is acceptable at step 55. The content manager server 6 may then transmit a decryption key to the user that will provide the user with viewing access to the broadcast content program at step 56. The process for sending the decryption key to the user is described in more detail below with reference to FIG.

However, if the price offer is not acceptable (ie, decision 51 = no), then at step 52 the content manager server 6 may send a counter offer to the user via a bidirectional link on the unicast network 5. The content manager server 6 then waits for the user's response to the counter offer in step 53. If the counter offer is accepted by the user, the user's mobile device 10 may send an acceptance message to the content manager server 6. When mobile device 10 receives a user input to accept a counter offer, mobile device 10 generates and sends a new dynamic price offer that identifies a price offer included in the counter offer of content manager server 6. You may. Upon receipt of the new dynamic price offer, the content manager server 6 will accept the new dynamic price offer as including a previously acceptable price offer. Alternatively, mobile device 10 may generate an indication that the counter offer is acceptable and transmit to content manager server 6. Alternatively, if the user selects a counter offer with a different price offer, then at step 50 the content manager server 6 receives a user request for broadcast content with a different price offer, and in decision 51 whether the price offer is acceptable. Determine.

One of a number of negotiation algorithms may be used by the content manager server 6 to enable dynamic price negotiation. For example, a minimum acceptable price of viewing access for the broadcast content program may be established. If the price suggested by the user is less than the minimum acceptable price, the difference between the minimum acceptable price and the price suggested by the user may be calculated. The content manager server 6 may generate and send a counter offer price, whereby the difference between the counter offer price and the minimum acceptable price is equal to or equal to the difference between the minimum acceptable price and the price suggested by the user. Ratio. In this way, the content manager server 6 may continue to generate and send counter offers until a minimum acceptable price or some price greater than the minimum acceptable price is offered and / or accepted by the user. .

4 is a process flow diagram illustrating an embodiment method 400 for initiating a content manager server 6 in a dynamic pricing mode. As an example of an embodiment method in operation, the pay-per-view program may be a live broadcast of a sporting event. The content manager server 6 may generate a content packet description (CPD) that describes the broadcast content program and contains various information including the static price for which the viewing access is to be granted. These CPDs may be broadcast to users in the form of a service guide in step 201. The content manager server 6 may receive a user request for a broadcast content program at a static price. As long as the content manager server 6 operates in the static pricing mode, the content manager server 6 may continue to grant the viewing access to the user only in exchange for the static price.

At some time before the actual broadcast time of the sporting event, the mobile TV broadcast service provider may choose to initiate a dynamic pricing mode. Thus, content manager server 6 may periodically determine whether the time remaining before the actual broadcast time at decision 202 exceeds some predetermined threshold. If the time to broadcast exceeds a predetermined threshold (ie, decision 202 = no), the content manager server 6 continues to insert the CPD into the service guide at a static price. However, if the time to actually broadcast is below a predetermined threshold (ie, decision 202 = yes), the content manager server 6 may change the CPD to remove the static price for the broadcast content program from the service guide in step 203. have. The absence of a static price in the service guide may indicate that the mobile TV broadcast service provider is now operating in dynamic pricing mode and accepting negotiable price offers from users.

Alternatively, the content manager server 6 may insert clear information in the service guide in which the mobile TV broadcast service provider operates in the dynamic pricing mode and accepts negotiable price offers from users. The content manager server 6 sets the negotiable flag to " 1 " to enable the dynamic pricing process, which is followed by the content manager server 6 (or price bid manager 9) in step 204. Processing may also accept a user negotiable price offer. The content manager server 6 may also set a minimum acceptable price for viewing access to the broadcast content program at step 205. Once the negotiable flag and the minimum acceptable price are set, the content manager server 6 may perform the dynamic price negotiation process described in more detail below with reference to FIG. 5 at step 206. The mobile TV broadcast service provider may choose to perform the dynamic price negotiation process up to a predetermined predetermined time. This predetermined time may be before the start of the broadcast but may be extended to the end of the broadcast. For example, users may be allowed to negotiate a price to access broadcast content until the start of the scheduled broadcast content program.

Alternatively, the mobile TV broadcast service provider may allow the user to obtain viewing access to the "already in progress" broadcast content program. In some embodiments, the mobile TV broadcast service provider may initiate another dynamic price negotiation process by setting a minimum acceptable price for the viewing access request received after the broadcast content program begins to be broadcast. If the time for negotiating the price has not expired (ie, decision 207 = no), the content manager server 6 may continue to perform the broadcast content price negotiation process at step 206. However, if the time for negotiation has expired (ie, decision 207 = yes), the content manager server 6 resets the negotiable flag to "0" in step 208 and returns to step 201 to the other broadcast content program. The broadcast content information may be inserted into the service guide.

5 is a process flow diagram illustrating an embodiment method 500 for dynamic price negotiation. The content manager server 6 may receive a broadcast content viewing access request from users at step 210. In some cases, users may send a request for viewing access before the content manager server 6 operates in the dynamic pricing mode. In this case, the user requests viewing access to the broadcast content program for a static price. Thus, upon receipt of the user's viewing access request, the content manager server 6 to see if the negotiable flag in decision 211 is set to " 1 " indicating that the content manager server 6 is operating in dynamic pricing mode. You can also check. If the negotiable flag is not set to '1', the dynamic pricing operation cycle has not yet started, and broadcast content viewing access is only available to users for static prices. Thus, if the negotiable flag is not set to "1" (ie, decision 211 = no), the received broadcast content viewing access request may be treated as an agreement and charged a static price. The content manager server 6 may wait for confirmation of whether a token of the payment has been received at decision 217. Users may prepay, receive and store tokens on their mobile device 10, which may be exchanged for viewing access to the broadcast program. Some broadcast programs may require the submission of one or multiple tokens before viewing access is granted. In this way, money is no longer exchanged with viewing access. If no token or payment has been received (ie, decision 217 = no), the content manager server 6 may continue to wait for confirmation of receipt of the token / payment at decision 217. Once the token or payment is received (decision 217 = yes), the content manager server 6 (or a separate billing server in communication with the content manager server 6) may withdraw the payment from the user account in step 218 or the token. You may receive (s). The content manager server 6 may generate and send a message to the mobile device that the user has purchased access to the broadcast at step 219. The content manager server 6 may then begin the process to transmit the appropriate decryption key in step 220. The process for transmitting a suitable decryption key is described in more detail below with reference to FIG.

If the negotiable flag is set to "1" (ie, decision 211 = yes), the content manager server 6 requests the user's request to obtain the user's price offer (via the program response manager 9) in step 212. You can also analyze The content manager server 6 may then determine, at decision 213, whether the proposed price is more than the minimum acceptable price set in step 205 of FIG. 4. If the analyzed price suggested by the user is above the minimum acceptable price (ie, decision 213 = yes), the content manager server 6 accepts the user's price offer in steps 217-219, accepts the payment and accepts the appropriate cipher. You can also send a decryption key. If the price offer analyzed is less than the minimum acceptable price (ie, decision 213 = no), the content manager server 6 may generate and send a counter offer that includes the suggested price for viewing access in step 214. . As mentioned above, any of a variety of negotiation know-hows may be implemented by the content manager server 6 to generate a suitable counter offer. Once the counter offer is generated and sent back to the user via a bidirectional link in the unicast network 5, the content manager server 6 may wait for the user's acceptance, rejection or counter for the counter offer in step 215.

Various mechanisms may be used to link the decryption key for the subscription purchase. Typically, a mobile broadcast service is a unicast communication network, such as a consumer's cellular telephone data service for communicating subscription messages to / from a particular consumer mobile device, and a separate broadcast network for broadcasting mobile television programming to all mobile devices. Can also be used. In summary, the mobile broadcast service provider may transmit a message that includes information that causes the mobile device 10 to generate the decryption key needed to receive the particular broadcast. The decryption key may be configured to expire after a predetermined amount of time to enable pay-per-view (pay-per-play) type services as well as to limit the economic impact of the decryption key falling into the public domain. have. In addition, the message providing the decryption key may include service restriction parameters that may be used to limit the received broadcast service to a particular program, channel, or other market segment.

Various embodiments may be implemented within OMA BCAST technology, for example, by sending a temporary LTKM to consumers that will expire within a limited period of time when a user's account is charged for a negotiated program viewing price. When the LTKM is received, the mobile device may use that message content to decrypt some of the STKM messages to obtain a TEK to view the requested broadcast transmission.

6 is a process / message flow diagram illustrating an embodiment method 600 for providing a user with a suitable decryption key once the negotiation between the user and the mobile TV broadcast service provider is successfully completed. As described above with reference to FIGS. 4 and 5, the user may participate in the negotiation process with the mobile TV broadcast service provider via the content manager server 6 in steps 206 and 306. Once the negotiation has been successfully completed, the content manager server 6 may send a message to the user's mobile device 10 indicating a successful negotiation in step 219. In addition, the content manager server 6 may also send a message to the content provider server 8 informing the content provider server of the identity of the mobile device 10 of the user whose successful negotiation and successful negotiation have been performed in step 219. The successful negotiation message may be received by the user's mobile device 10 in step 319 as well as by the content provider server 8 in step 119. Upon receipt of a successful negotiation message, content provider server 8 may initiate a process for providing the user with a suitable decryption key to view the purchase broadcast program.

In response to the received successful negotiation message (step 119), the broadcast content provider 8 generates a long-term decryption key message, eg, LTKM, in step 123 for use by the user's mobile device 10 and generates a content manager server ( 6) can also be sent. This LTKM may include conditions and terms that the mobile device 10 can decrypt the TEK within the STKM to decrypt and display the content of the purchased program. The LTKM sent to the content manager server 6 may also include a restricted access key to allow the user to watch the broadcast program only for a predetermined limited period of time. The LTKM is transmitted using the unicast network 5.

At the same time, the broadcast content provider 8 also broadcasts a STKM as well as a continuous sequence of encrypted broadcast content in step 125. The content manager server 6 may receive and send the LTKM in steps 223 and 224. Mobile device 10 receives LTKM via unicast network 5 in step 324. The mobile device also receives the encrypted content stream and the STKM stream via the broadcast network 3 in step 325. Mobile device 10 may use LTKM to decrypt the TEK included in the STKM stream. The TEK is then used to decrypt the purchased broadcast content. If the broadcast content is decrypted, the mobile device may display the content to the user for viewing in step 326.

FIG. 7 shows a process / message flow 700 of another embodiment method for providing a user with a suitable decryption key when negotiation between a user and a mobile TV broadcast service provider is performed at the secondary user terminal. As mentioned above, in some embodiments, the user may wish to pre-order a program for receiving broadcast on the mobile device from the remote secondary user terminal 11. The process / message flow 700 shown in FIG. 7 is quite similar to the method 600 shown in FIG. 6. In process / message flow 700, the broadcast content price is negotiated between the secondary user terminal 11 and the content manager server 6 in steps 206 and 306. Upon completion of the successful negotiation, the content manager server 6 may transmit an indication of successful negotiation that may be received by the secondary user terminal 11 (step 319) as well as the content provider 8 (step 119). (Step 219). As above, the broadcast content provider 8 may generate and send a long term decryption key message, such as LTKM, to the content manager server 6 in step 123 for use by the user's mobile device 10. The LTKM sent to the content manager server 6 may also include a restricted access key to allow the user to watch the broadcast program for only a limited time period.

At the same time, the broadcast content provider 8 also broadcasts a STKM as well as a continuous sequence of encrypted broadcast content in step 125. The content manager server 6 may receive and send the LTKM in steps 223 and 224. Mobile device 10 receives LTKM via unicast network 5 in step 324. Mobile device 10 also receives an STKM stream and an encrypted content stream via broadcast network 3 in step 325. Mobile device 10 may use LTKM to decrypt the TEK included in the STKM stream. The TEK is then used to decrypt the purchased broadcast content. If the broadcast content is decrypted, the mobile device may display the content to the user for viewing in step 326.

8 is a process flow diagram illustrating an embodiment method 800 performed by various elements in a broadcast system in an embodiment negotiation. The content manager server 6 may transmit a service guide including information about various broadcast content programs in step 201. A static price for obtaining viewing access to broadcast content may be included with this information. Via mobile TV broadcast transmission 3, users may receive a service guide with a fixed price on that mobile device 10 in step 301. Users may choose to request viewing access to the broadcast content program described in the Service Guide at a fixed price (not shown).

When the content manager server 6 transmits the service guide, the content manager server may periodically monitor the time remaining before the broadcast time for the broadcast content program. If the time remaining before the broadcast is less than the predetermined threshold (ie, decision 202 = no), the content manager server 6 may continue to transmit a service guide that includes the static price for the broadcast content program in step 201. Once the time remaining before the broadcast is less than the predetermined threshold (ie, decision 202 = yes), the content manager server 6 may transmit a service guide update without pricing information about the particular broadcast content program at step 203. For example, the content manager server 6 may update the "purchase data" fragment of OMA-BCAST in the transmission (assuming that other parts of the service guide will not be charged).

By sending the service guide without any pricing information, the content manager server 6 indicates to the mobile device 10 that the price for viewing the broadcast program is negotiable. In another embodiment, the content manager server 6 may send a service guide update with a clear message indicating that the price for viewing the broadcast program is negotiable. Users may receive a service guide without pricing information (or with clear information about negotiable prices) for the mobile device 10 at step 303. In response to receiving the information that the price is negotiable, the mobile device 10 may prompt the user to enter a price offer and receive input of the user of the negotiable price offer in step 304. Once the user's request and price offer are received, the mobile device 10 may transmit information to the content manager server 6 via the unicast network in step 310.

The content manager server 6 receives the user's request in step 210 and performs steps 211-220 as described above with reference to FIG. When the content manager server 6 responds to the counter offer in step 214, the user's mobile device 10 may receive the counter offer in step 314 and display the counter offer to the user in step 315. The user may then respond to the counter offer by accepting the counter offer, suggesting a counter to the counter offer, or rejecting the offer. Mobile device 10 may receive a user input response in step 316 and determine whether the user accepts the offer in decision 317. If the user indicates that the counter offer is acceptable (ie, decision 317 = yes), the mobile device 10 may send the counter offer to the content manager server 6 as the new suggested price at step 318. Since the new proposed price is already acceptable to the content manager server 6, the user's counter offer will be acceptable to the content manager server 6. As a result, when the counter offer is received in step 210 and analyzed in step 211, the content manager server 6 accepts the counter to allow viewing access in steps 217-220 of FIG. 5 and sequentially generates a suitable decryption key. Will send. Alternatively, mobile device 10 may send a message to content manager server 6 accepting the counter offer, in which case content manager server 6 may use the static price as described above with reference to FIG. 5. May proceed the transaction in a similar manner as when it accepts (eg, decision 211 = no; steps 217-220).

Alternatively, the user may choose to counter the counter offer. If the mobile device 10 determines from the user input that the counter of the content manager server 6 is not acceptable (ie, decision 317 = no), the mobile device 10 rejects the counter offer or sets the counter for the counter offer. The user may be prompted to indicate whether the user wishes to do. Mobile device 10 may receive a user input and determine whether the user wants to accept or decline a counter offer at decision 230. If the mobile device 10 determines that the user rejects the counter offer (ie, decision 230 = no), the mobile device 10 sends a message affecting the content manager server 6 via the unicast network in step 322. The broadcast request may be interrupted by transmitting. If the mobile device 10 determines that the user wants to counter the counter offer (ie, decision 320 = yes), the mobile device prompts the user to enter a counter offer price in the counter offer received from the content manager server 6. You may. The mobile device 10 receives the counter price from the user and transmits the information to the content manager server 6 in a manner similar to the original request with the new proposed price in step 321. Upon receipt of the counter for the counter offer in step 210, the content manager server 6 evaluates the counter for the counter offer and proposes in a similar manner as described above with reference to steps 210-220 of FIG. 5. It may also accept or counter the most recently received counter offer. This process may continue until mutual consent is reached or until the user chooses to abort the negotiation. In some embodiments, the process may be allowed to undertake a limited number of iterations to minimize the consumption of network resources (eg, unicast network bandwidth).

9 shows a service guide data model 900, where data is represented as an XML fragment. Each XML fragment is considered to be a separate well formed XML document. XML text declarations may be omitted. In this case, the mobile device 10 may assume the following default XML text declaration as follows to ensure well-formedness:

<? xml version = "1/1"?>

The namespace used for the fragment must be declared in the fragment according to XML rules. If no namespace is declared, the mobile device may assume that the default namespace of the fragment is "urn: oma: xml: bcast: sg: fragments: 1.0".

The cardinality shown in the service guide data model 900 of FIG. 9 has the following meaning. One instance of fragment A refers to the c to d instance of fragment B. If c = d, d is omitted. Thus, if c> 0 and fragment A is present, then at least c instances of fragment B must also be present, but there may be a maximum d instance of fragment B. Conversely, one instance of fragment B is referenced by the a through b instances of fragment A. If a = b, b is omitted. An arrow link from fragment A that points to fragment B indicates that fragment A contains a reference to fragment B.

Any given 'purchase item' fragment may refer to only a single type of the following fragments: 'service', 'schedule', 'content', or other 'purchase item'. The 'access' fragment may have a connection to either the 'service' fragment or the 'schedule' fragment.

As shown in FIG. 9, all of the connection arrows between the service guide fragments are unidirectional, except for two pairs of opposite unidirectional arrows: between the 'schedule' fragment and the 'bidirectional data' fragment; And between the 'access' fragment and the 'preview data' fragment. A reference arrow from the 'schedule' fragment to the 'bidirectional data' fragment declares a distribution schedule of the interactive media documents carried in the file stream (referenced by the 'bidirectional data' fragment). A reference arrow from a 'bidirectional data' fragment to a 'schedule' fragment declares a 'schedule' fragment with which the 'bidirectional data' fragment is associated. A reference arrow from the 'access' fragment to the 'preview data' fragment indicates a service-by-service switching preview information for access. A reference arrow from the 'preview data' fragment to the 'access' fragment declares how the preview data can be accessed.

The semantics of the elements in the model are defined as follows; The 'service' fragment is described at the aggregation level of the content items including the broadcast service. The service may be delivered to the user using multiple access means, such as broadcast channels and interactive channels. The service may target a given user group or geographic area. Depending on the type of service, it may have mutual part (s), broadcast-only part (s) or both.

The service may further include components not directly related to the content but directly related to user capture, such as purchase or subscription information, related to the functionality of the service. As part of the service guide, the 'service' fragment forms a central hub referenced by other fragments, including the 'access', 'schedule', 'content' and 'purchase item' fragments. In addition, the 'service' fragment may refer to the 'preview data' fragment. The 'preview data' fragment may not be referenced by any of each of these fragments or may be referenced by some of each of these fragments.

With the associated fragments, mobile device 10 may determine the details associated with the service at any point in time. These details may be summarized, for example, as a user-friendly display of what, how and when associated content may be consumed and at what price.

The 'schedule' fragment defines a timeframe in which associated content items are available for streaming, downloading and / or rendering. This fragment refers to the 'service' fragment. Furthermore, referring to one or more 'content' fragments or 'interactive data' fragments, a valid distribution and / or presentation time frame of these content items belonging to the service, or a valid distribution time frame and automatic activation time of interactive media documents associated with the service Define. On the other hand, if the 'schedule' fragment does not refer to any 'content' fragment (s) or 'interactive data' fragment (s), it defines a timeframe of unbound service availability.

The 'content' fragment provides a detailed description of a particular content item. In addition to defining the type, description and language of the content, it may also provide information about the genre and parent rating as well as the targeted user group or geographic area.

The 'content' fragment may be referenced by a schedule, purchase item or 'interactive data' fragment. Reference may be made to the 'preview data' fragment or the 'service' fragment.

The 'access' fragment describes how a service may be accessed for the life of the service. This fragment contains or references the session description information and indicates the delivery method. One or more 'access' fragments may refer to 'service' fragments that suggest alternative ways to access or interact with associated services.

For mobile device 10, the 'access' fragment provides information about the capability required from mobile device 10 to receive and render a service. The 'access' fragment provides session description parameters in inline text form or via a pointer in the form of a URI to a separate session description. The session description information may be delivered through either a broadcast channel or an interactive channel.

'Session Description' is a service guide fragment that provides session information for access to a service or content item. The session description may also provide assistance description information used in the associated delivery procedures.

The session description information may be provided using either syntax of the SDP in text format or 3GPP MBMS user service bundle description [3GPP TS 26.346] (USBD).

The supplementary description information may be provided in an XML format or may include an associated delivery description as specified in [BCAST 10-Distribution].

If SDP syntax is used, an alternative way to convey the session description is to encapsulate the SDP in a text format in an 'access' fragment.

Session descriptions, such as concepts, may be used for both the service guide delivery itself as well as for content sessions.

The 'buyitem' fragment represents one or more service groups (ie, a service bundle) or one or more content items proposed to the end user for free to subscribe and / or purchase.

This fragment may be referenced by the 'purchase data' fragment (s) which suggests more information on different service bundles. The 'purchase data' fragment may also be associated with:

● the 'service' fragment and / or to enable the bundled service subscription;

'Schedule' fragments and / or to make it possible to consume content (pay-per-view functionality) or a given service in a given time frame;

A 'content' fragment to make it possible to purchase a single content file related to the service, and

Purchase Items Other 'purchase data' fragments to enable bundling of purchase data.

The main function of the 'purchase data' fragment is to represent all available pricing information for the associated purchase item.

The 'purchase data' fragment collects information about one or several purchase channels and may be associated with preview data specific to a particular service or service bundle. Return information regarding the pricing of a service, service bundle, or content item. Information about promotional activities may also be included in this fragment.

The 'buy channel' fragment returns information about an entity, i.e., a content provider or an aggregator, from which the access to a particular service, service bundle or content item and / or purchase of the content is 'purchase data' It may be obtained as defined in the fragment. The purchase channel is associated with one or more mobile TV service providers. The mobile device is also only authorized to access a particular purchase channel when associated with a mobile TV service provider associated with that purchase channel.

Multiple purchase channels may be associated with one 'purchase data' fragment. In other words, the same price term for subscribing to a program may be simultaneously proposed by different mobile TV providers. A given end-user may have a "preferred" purchase channel (eg his / her mobile operator) to which all purchase requests are directed. The preferred purchase channel may be the only channel allowed for use by the end-user.

Since the 'preview data' fragment contains information used by the mobile device to represent the service or content outline to the users, the users may have a general idea of what service or content they are about. The 'preview data' fragment may include simple text, a fixed image (eg a logo), a short video clip, or may refer to another service, which may be a low bit rate version for the main service. The 'service', 'content', 'purchase data', 'access' and 'schedule' fragments may refer to the 'preview data' fragment.

The interactive data includes information used by the mobile device to suggest a mutual service to a user associated with the broadcast content. These interactive services may allow a user to vote during a TV show or to obtain content related to broadcast content. The "interactive data" fragment refers to one or many "interactive media" documents, including HTML files, static images, email templates, SMS templates, MMS template documents, and the like. The 'interactive data' fragment may refer to the 'service', 'content' and 'schedule' fragments, or may be referred to by the 'schedule' fragment.

The Service Guide Delivery Descriptor (SGDD) is sent on the service guide notification channel and informs the mobile device of the grouping, metadata and availability of fragments of the service guide in the service guide discovery process (see section 6.1.1.). SGDD allows for quick identification of service guide fragments that are cached or transmitted at the mobile device. For that reason, the SGDD is preferably repeated when distributed over the broadcast channel. SGDD also provides a means for determining the grouping of related service guide fragments and thus the completion of such groups.

The service guide delivery descriptor is particularly useful when the mobile device moves from one service coverage to another. In this case, the service guide delivery descriptor may be used to quickly check whether the service guide fragment received in the previous service coverage area is still valid in the current service coverage area, and thus does not need to be re-analyzed and re-processed.

The service request is sent by the mobile device 10 to the content manager server 6 to request a subscription for the associated purchase item or to request the purchase of the associated purchase item. If the price is specified in the requested message and it is different from the price calculated by the content manager server 6 for one or more of the purchase items included in the request, the content manager server 6 responds to the pricing information response message. You may respond. Also, if the price is not specified for one or more of the purchased items in the requested message, the content manager server 6 may respond to the pricing information response message. If not, the content manager server 6 may respond to the service response message.

The pricing information response message includes a purchase item and a purchase data fragment element. The purchase item element describes the price information of the purchase item and includes a purchase data reference element. The purchase item also includes a price element with a currency attribute and validTo along with the negotiable element. If there is no 'price' in this pricing information response message, then this element indicates that the purchase price is negotiable in subsequent purchase transactions.

If 'negotiable' = true or 1, this indicates that the currency price of the referenced purchase item is negotiable (ie, the user can submit a price offer with a subsequent service request or token purchase request message).

If 'negotiable' = false or 0, this indicates that the currency price of the referenced purchase item is not negotiable with the user (ie, the user can accept the static price offer with a subsequent service request or token purchase request message). ).

The purchase data fragment is specified in [BCAST10-SG] which contains a price associated with the information about the requested purchase item (s). A fragment of either the 'purchase data reference' fragment or the 'purchase data fragment' fragment, but not both, may be exemplified by the 'price information response' message.

The service request message may include the following elements: user ID; Device ID; Service encryption protocol; Purchase item; And Drm profile specific part or smart card profile specific part. In the case of a smart card profile, a 'smart card profile specific part' may be omitted if the message is used for subscription or purchase purposes, or the message is used to request delivery of SEK (s) / PEK (s). It may be included if

The purchase item element includes a list and price of items that the user wants to order and a list of services that the user wants to subscribe to. The purchase item includes a purchase data reference, a price, a suggested price, and a service element. The offer price element represents a price offer by the user for the purchase of the referenced purchase item. The (optional) presence may be triggered by either of two events: a) the price of the purchase item is signaled in the 'purchase data fragment' element of the 'price information response', 'Negotiable' attribute = true or 1, or b) The user / mobile device determines from the service guide that the purchase price is negotiable (ie, there is no 'currency price' element in the purchase data fragment).

The service response message may be sent from the content manager server 6 to the mobile device in response to the request for subscribing to the service request message. This message is applicable to both DRM profiles and smart card profiles. The service response message includes a purchase item element that describes the result of the request message to subscribe to or purchase the purchase item. In the DRM profile, if the subscription or purchase is successful, the rights valid end time of the purchase item will be expressed. In either the DRM profile or the smart card profile, in case of a subscription / purchase failure, the item WiseStatusCode will be expressed to indicate why the request is not accepted by the content manager server 6. The purchase item element includes an Acceptability element that the service request includes the element 'suggested price' and indicates whether the price offer is accepted by the content manager server 6. 'Acceptability' = true or 1 indicates that the price proposed from the user for the purchase of this purchase item, as included in the 'service request' message, is accepted by the content manager server 6. 'Acceptability' = false or 0 indicates that the price proposed from the user for the purchase of this purchase item as included in the 'service request' message is not accepted by the content manager server 6. The acceptability element includes a counterprice element that indicates 'acceptability' = false or 0, the presence of which indicates that the counter offer price from the content manager server 6 is accepted for this purchase item.

The token purchase request message and the token purchase response message may be configured similarly to the service request message and the service response message.

10 is a process flow diagram illustrating an alternative dynamic pricing method 1000 that may be implemented by the content manager server 6. Rather than conduct a negotiating process or accept conventional static pricing for pricing of viewing access, various auctions may be implemented to reach an acceptable price for viewing a broadcast program. In the auction method 1000 shown in FIG. 10, a seller (eg, a mobile TV broadcast service provider) informs the broadcast program of a high initial quote for viewing. The quotation is lowered at predetermined time intervals. As the price is lowered, users may send a purchase request to the content manager server 6 indicating that they are willing to purchase the broadcast content program at the current quote. The quote may continue to be lowered until the maximum number of subscriptions proposed through the auction is reached or a predetermined reserve price is reached. Once the end point is reached, the final quote may be billed to all users to whom the purchase request has been sent and in turn may receive the viewing privilege. Viewing access is granted only to users who have submitted a purchase request. Thus, if the maximum number of subscriptions are obtained before the desired price of potential users is known, it may be impossible for potential users who have delayed bid submission in the hope of lower prices to view the program. Thus, users interested in the broadcast program are motivated to accept higher quotes to ensure that they can purchase viewing privileges. Similarly, users who initially submit a bid must be prepared to risk filling the maximum number of subscriptions initially. As a result, these users may pay more for the broadcast content program than originally intended.

Other auction variants may be implemented. For example, rather than all bidders pay the final price, each bidder may be required to pay the purchase quote. For example, a mobile TV broadcast service provider may inform all potential bidders that only a limited number of subscriptions will be available through the auction. To ensure that they are able to obtain viewing access, bidders may choose to submit a bid initially at a higher price. Those bidders who later want to ensure viewing access in contrast to bidders who are bidding and risking not obtaining viewing access may initially be required to pay a higher price.

In another embodiment, the mobile TV broadcast service provider may limit the number of subscriptions available at a given price. Once all of the limited number of subscriptions are filled at a given price, the offer price may be lowered. By decreasing the number of subscriptions available at a particular price as the quote is lowered, potential bidders are encouraged to bid to ensure that they receive viewing access.

In another embodiment, the mobile TV broadcast service provider may choose to lower the bid price at predetermined intervals. However, because potential bidders do not know what the minimum auction price is, the potential bidders do not know when the auction will end. If a potential bidder delays submitting a purchase request with the hope that the price will continue to be lowered, the auction may end before the bidder submits a purchase request.

10 is a process flow diagram of an embodiment method 1000 that may be implemented by content manager server 6 to provide a type of auction that is well suited to a broadcast environment. As described above, the content manager server 6 generates a CPD for the broadcast content program and inserts it into the service guide transmitted to the mobile TV users via the broadcast network 3. The content manager server 6 may insert the broadcast content information into the service guide indicating that the specific broadcast content program is available via auction in step 225. CPDs may provide users (potential bidders) with specific rules governing the auction. For example, content manager server 6 may indicate that users must submit a bid to obtain viewing access, that the auction may end when the number of accepted bids exceeds a certain threshold or the minimum auction price is met. May be informed that the bid price will be lowered periodically, and that the price to be charged to each user may be determined by the final requested bid accepted at the auction.

After the rules of the auction are fully broadcast to the users, the content manager server 6 may set an initial quote price at step 230. The content manager may also set the response counter to zero (0) in step 235. At this time, the content manager server 6 may start an auction and begin receiving purchase requests or bids from users in step 240. When each bid or purchase request is received, the content manager server 6 records and stores an identifier for the mobile device 10 of the user making the purchase request or broadcast content program request bid in step 245. The content manager server 6 then increments the bid counter at step 250 and determines at decision 255 if the total number of bids is equal to the maximum number of subscriptions available through the auction process. If the number of bids is equal to the maximum number of available subscriptions (ie, decision 255 = yes), the content manager server 6 may close the auction and record the final quote in step 275. Once the auction is closed, the content manager server 6 withdraws the payment or the token in the amount of the final quote from each user account associated with the identifier stored in step 245 either directly in step 218 or through a billing server (not shown). You can get it. The content manager server 6 may then send a message to each mobile device associated with the stored identifiers of successful subscriptions in step 219. The content manager server 6 may then initiate the necessary steps in step 220 to transmit the appropriate decryption key to each mobile device associated with the stored identifier, for example via a process as described above with reference to FIG. 6. have.

If the number of bids is not equal to the maximum number of subscriptions available (ie, decision 255 = no), the content manager server 6 may determine whether more bid or purchase requests are being received at decision 260. If more bids are being received (ie, decision 260 = yes), the content manager server 6 may return to step 240 to continue receiving a bid or purchase request from other user mobile devices. If no more bids are received (ie, decision 260 = no), the content manager server 6 may determine whether the lowest auction price has been reached in decision 265. If the lowest auction price has been reached (ie, decision 265 = yes), the content manager server 6 may close the auction in step 275 and perform steps 218-220 as described above. However, if the lowest auction price has not been reached (ie, decision 265 = no), the content manager server 6 may lower the bid price at step 270 and return to step 240 to request additional bid or purchase requests from the users. May be received.

FIG. 11 is a process flow diagram illustrating an auction method 1100 of another embodiment in which a quote is billed at the time of submitting a purchase request as opposed to the user being billed for the final quote, such as the embodiment shown in FIG. 10. The auction method 1100 of the embodiment shown in FIG. 11 also allows the content manager server 6 to increase the bid price as well as the option to decrease the bid price. In some cases, for example, when program broadcast time is approaching, the price a user is willing to pay for viewing access may increase. Alternatively, after the broadcast content program is started and broadcast, the price the user is willing to pay for viewing access may decrease.

Similar to the method 1000 described above with reference to FIG. 10, the content manager server 6 may insert information regarding specific auction rules into the service guide at step 225. Once the auction rules have been broadcast to the users enough to inform the users of the auction and its rules, the content manager server 6 may set an initial quote at step 230. Once the initial quote is set, the auction may begin and the content manager server 6 may receive a purchase request or broadcast content request response at the current quote at step 231. When a broadcast content program request response is received, the content manager server 6 (or billing server) transmits an appropriate decryption key for viewing access at step 220 and receives the payment as described above with reference to FIG. 5. You may perform steps 217-220. The content manager server 6 may periodically determine whether it is time to adjust the call price at decision 232. If the time for adjusting the quotation has not yet elapsed (ie, decision 232 = no), the content manager server 6 returns to step 231 and continues receiving the broadcast content program request response or purchase request. If the time for adjusting the price has elapsed (ie, decision 232 = yes), then the content manager server 6 determines in step 233 whether additional proposed quote level is available. In other words, the content manager server 6 may determine whether the minimum auction price was met when the quotation was reduced or whether the maximum bid was met at the auction when the quotation was increased. If no further proposed call price level is available (ie, decision 233 = no), the content manager server 6 may close the auction in step 275 and no longer accept the broadcast program purchase request. If additional proposed call price levels are available (ie, decision 233 = yes), the content manager server 6 may increase (or decrease) the call price for the broadcast program at step 234. Once the quote has been adjusted, the content manager server 6 may return to step 231 to accept the purchase request or additional user bids at the adjusted bid price level. In this way, each user who submits a bid or purchase request is quoted when the user submits their bid or purchase request.

12 is a process flow diagram of another embodiment auction method 1200 in which a limited number of subscriptions are available at each price level of an auction. Similar to the auction method 1000 described above with reference to FIG. 10, in the method 1200, the content manager server 6 informs users of auction rules via the service guide in steps 225-240 and sets an initial quote. Set the counter to zero and begin receiving bids from users. However, in contrast to the auction method 1000 described above with reference to FIG. 10 but similar to the auction method 1100 described above with reference to FIG. 11, individual users are charged a quote when they make a purchase request. Accordingly, the content manager server 6 receives the payment, notifies the user of a successful purchase, and transmits a decryption key suitable for viewing access, as in steps 217-220 described above. As each bid or purchase request proceeds and a decryption key is sent (step 220), the bid counter is incremented at step 237. The content manager server 6 then determines in step 238 whether the maximum number of subscriptions available for the current quote is sold. If the maximum number of subscriptions for the current price level has not been sold yet (ie, decision 238 = no), the content manager server 6 will continue to receive bid or purchase requests at the current price by returning to step 240. However, if the maximum number of subscriptions for the current quote price has been sold (ie, decision 238 = yes), the content manager server 6 determines whether there is another price level to propose subscriptions in decision 233. If there are no more available call price levels (ie, decision 233 = no), the content manager server 6 may close the auction in step 275 and no longer accept the broadcast program purchase request. If additional proposed call price levels are available (ie, decision 233 = yes), the content manager server 6 may increase (or decrease) the call price for the broadcast content at step 234. Once the quote has been adjusted, the content manager server 6 may return to step 235 to reset the counter that counts the number of subscriptions sold at the particular quote.

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

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

In addition, many of the embodiments described above may be implemented in any of a variety of general purpose computer or remote server devices, such as the server 2400 shown in FIG. 14. Typically, such server 2400 includes a large capacity nonvolatile memory, such as disk drive 2403, and a processor 2201 coupled to volatile memory 2402. The server 210 may also include a compact disk (CD) drive 2406 and / or a floppy disk drive coupled to the processor 2401. In addition, server 210 may include network access ports 2404 coupled to processor 2401 to communicate with a network 2405, such as the Internet.

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

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

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

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

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

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

Claims (60)

A method for dynamically pricing viewing access for a mobile TV broadcast program, the method comprising:
Broadcasting over the mobile TV broadcast network a dynamic pricing message indicating that viewing access to the broadcast program is available through dynamic pricing, wherein the dynamic pricing message is an initial call price representing an upper bound on bid. Broadcasting the dynamic pricing message to set a value;
Receiving a dynamic price offer for viewing access to the broadcast program from a mobile device via a unicast network;
Determining whether the dynamic price offer is acceptable based on an initial quote that represents an upper limit for the bid; And
And sending decryption key information over the unicast network to the mobile device that will enable the mobile device to access the broadcast program if the dynamic price offer is determined to be acceptable. Way. The method of claim 1,
Sending a counter offer price to the mobile device if the dynamic price offer is determined to be unacceptable. 3. The method of claim 2,
Broadcasting a static pricing message over the broadcast network indicating that viewing access to a broadcast program is available via static pricing;
Receiving a purchase request from the mobile device;
In response to receiving the purchase request, transmitting decryption key information to the mobile device over the unicast network that will enable the mobile device to access the broadcast program; And
Determining whether a predetermined time threshold has been exceeded before broadcasting the dynamic pricing message. The method of claim 3, wherein
The dynamic price offer is determined to be acceptable if it is greater than the minimum acceptable price,
Wherein the minimum acceptable price is less than a static price offer. The method of claim 3, wherein
The dynamic price offer is determined to be acceptable if it is greater than the minimum acceptable price,
Wherein the minimum acceptable price is greater than a static price offer. The method of claim 1,
The dynamic pricing is an auction process and the dynamic price offer is a purchase request to access the broadcast program at a current asking price,
The dynamic pricing method,
Storing an identifier of the mobile device from which the purchase request was received;
Determining whether additional subscriptions are available for purchase;
Closing the auction process if additional subscriptions are not available for purchase;
Determining whether the current quote is equal to a reserve price;
Decreasing the quotation if the current quotation exceeds the minimum auction price;
Closing the auction process if the current bid price is equal to the minimum auction price; And
Billing the current quote to a user account associated with the stored identifier when the auction process is closed prior to transmission of the decryption keys. The method of claim 1,
The dynamic pricing is an auction process and the dynamic pricing offer is a bid for viewing access to a broadcast content program at a current published quote,
The dynamic pricing method,
Charging the current quote to a user account prior to sending the decryption keys;
Determining whether time for adjusting the current call price has elapsed;
Determining if the current bid price exceeds a minimum auction price;
Adjusting the current price if the time for adjusting the current price has elapsed and the minimum auction price is not met; And
Closing the auction process if the current bid price does not exceed the minimum auction price. The method of claim 7, wherein
Adjusting the current bid price comprises increasing the current bid price. The method of claim 7, wherein
And adjusting the current bid price comprises decreasing the current bid price. The method of claim 1,
The dynamic pricing is an auction process and the dynamic price offer is a purchase request to access the broadcast program at a current quote,
The dynamic pricing method,
Charging the current quote to a user account prior to sending the decryption keys;
Determining whether additional subscriptions for accessing the broadcast program are available at the current quotation;
Determining if the current bid price exceeds a minimum auction price;
Adjusting the current offer price if additional subscriptions for viewing access to the broadcast content are not available at the current offer price and the current offer price exceeds the minimum auction price; And
Closing the auction process if the current bid price does not exceed the minimum auction price. 11. The method of claim 10,
Adjusting the current bid price comprises increasing the current bid price. 11. The method of claim 10,
And adjusting the current bid price comprises decreasing the current bid price. A method for obtaining viewing access to dynamically priced mobile TV broadcast programs, the method comprising:
Receiving via the mobile TV broadcast network a broadcast dynamic pricing message indicating that viewing access to the broadcast program is available through dynamic pricing, wherein the broadcast dynamic pricing message is an upper bound on bid. Receiving the broadcasted dynamic pricing message, setting an initial quote that indicates
Displaying the broadcast dynamic pricing message;
Receiving a dynamic price offer entered for viewing access to the broadcast program based on an initial quote that represents an upper limit for the bid;
Transmitting the input dynamic price offer to a server in a mobile TV broadcast network via a unicast network; And
Receiving decryption key information for enabling access to the broadcast program from the server in the mobile TV broadcast network via the unicast network. The method of claim 13,
Receiving a counter offer price from the server in the mobile TV broadcast network;
Displaying the received counter offer price;
Receiving a user input response to the displayed counter offer price; And
Sending a counter for the counter offer price to the server in the mobile TV broadcast network via the unicast network. 15. The method of claim 14,
And if the received user input response indicates acceptance of the counter offer price, the counter for the counter offer price is equal to the counter offer price. 15. The method of claim 14,
And the counter for the counter offer price is lower than the counter offer price if the received user input response indicates a rejection of the counter offer price. A server in a mobile TV broadcast network,
Means for broadcasting over a mobile TV broadcast network a dynamic pricing message indicating that viewing access to a broadcast program is available through dynamic pricing, wherein the dynamic pricing message is for bid. To set the initial quote price indicating the upper limit. Means for broadcasting the dynamic pricing message;
Means for receiving a dynamic price offer for viewing access to the broadcast program from a mobile device via a unicast network;
Means for determining whether the dynamic price offer is acceptable based on an initial quote that represents an upper limit for the bid; And
Means for transmitting decryption key information over the unicast network to the mobile device that will enable the mobile device to access the broadcast program when the dynamic price offer is determined to be acceptable. The method of claim 17,
Means for sending a counter offer price to the mobile device if the dynamic price offer is determined to be unacceptable. The method of claim 18,
Means for broadcasting over the broadcast network a static pricing message indicating that viewing access to a broadcast program is available via static pricing;
Means for receiving a purchase request from the mobile device;
Means for transmitting decryption key information over the unicast network to the mobile device that will enable the mobile device to access the broadcast program in response to receiving the purchase request; And
Means for determining if a predetermined time threshold has been exceeded before broadcasting the dynamic pricing message. The method of claim 19,
The dynamic pricing is an auction process and the dynamic price offer is a purchase request to access the broadcast program at a current asking price,
The server comprises:
Means for storing an identifier of the mobile device from which the purchase request was received;
Means for determining if additional subscriptions are available for purchase;
Means for closing the auction process if additional subscriptions are not available for purchase;
Means for determining if the current quote is equal to a reserve price;
Means for reducing the quoted price if the current quoted price exceeds the minimum auction price;
Means for closing the auction process if the current bid price is equal to the minimum auction price; And
Means for charging the current quote to a user account associated with the stored identifier when the auction process is closed prior to transmission of the decryption keys. The method of claim 17,
The dynamic pricing is an auction process and the dynamic pricing offer is a bid for viewing access to a broadcast content program at a current published quote,
The server comprises:
Means for charging the user account for the current quote;
Means for determining whether time for adjusting the current call price has elapsed;
Means for determining if the current bid price exceeds a minimum auction price;
Means for adjusting the current quotation when the time for adjusting the current quotation has elapsed and the minimum auction price is not met; And
Means for closing the auction process if the current quotation does not exceed the minimum auction price. 22. The method of claim 21,
Means for adjusting the current quote price comprises means for increasing the current quote price. 22. The method of claim 21,
Means for adjusting the current quote price comprises means for decreasing the current quote price. The method of claim 17,
The dynamic pricing is an auction process and the dynamic price offer is a purchase request to access the broadcast program at a current quote,
The server comprises:
Means for charging the user account for the current quote;
Means for determining whether additional subscriptions for accessing the broadcast program are available at the current quotation;
Means for determining if the current bid price exceeds a minimum auction price;
Means for adjusting the current offer price if additional subscriptions for viewing access to the broadcast content are not available at the current offer price and the current offer price exceeds the lowest auction price; And
Means for closing the auction process if the current quotation does not exceed the minimum auction price. 25. The method of claim 24,
Means for adjusting the current quote price comprises means for increasing the current quote price. 25. The method of claim 24,
Means for adjusting the current quote price comprises means for decreasing the current quote price. A mobile device capable of watching mobile TV broadcast programs,
Means for receiving via a mobile TV broadcast network a broadcasted dynamic pricing message indicating that viewing access to a broadcast program is available through dynamic pricing, wherein the broadcasted dynamic pricing message is a response ( means for receiving the broadcasted dynamic pricing message that sets an initial quote that indicates an upper bound for bid);
Means for displaying the broadcast dynamic pricing message;
Means for receiving a dynamic price offer entered for viewing access to the broadcast program based on an initial quote that represents an upper limit for the bid;
Means for transmitting the input dynamic price offer to a server in a mobile TV broadcast network via a unicast network; And
Means for receiving decryption key information to enable access to the broadcast program from the server in the mobile TV broadcast network via the unicast network. The method of claim 27,
Means for receiving a counter offer price from the server in the mobile TV broadcast network;
Means for displaying the received counter offer price;
Means for receiving a user input response to the displayed counter offer price; And
Means for transmitting a counter for the counter offer price to the server in the mobile TV broadcast network via the unicast network. 29. The method of claim 28,
And if the received user input response indicates acceptance of the counter offer price, the counter for the counter offer price is equal to the counter offer price. 29. The method of claim 28,
And the counter for the counter offer price is lower than the counter offer price if the received user input response indicates a rejection of the counter offer price. A server for dynamically pricing viewing access to mobile TV broadcast programs,
A server memory unit; And
A server processor coupled to the server memory unit,
The server processor,
Broadcasting over the mobile TV broadcast network a dynamic pricing message indicating that viewing access to the broadcast program is available through dynamic pricing, wherein the dynamic pricing message is an initial call price representing an upper bound on bid. Broadcasting the dynamic pricing message to set a value;
Receiving a dynamic price offer for viewing access to the broadcast program from a mobile device via a unicast network;
Determining whether the dynamic price offer is acceptable based on an initial quote that represents an upper limit for the bid; And
Transmitting decryption key information over the unicast network to the mobile device that will enable the mobile device to access the broadcast program if the dynamic price offer is determined to be acceptable. A server, consisting of software instructions. The method of claim 31, wherein
The server processor,
Software instructions that further perform the step of sending a counter offer price to the mobile device if the dynamic price offer is determined to be unacceptable. 33. The method of claim 32,
The server processor,
Broadcasting a static pricing message over the broadcast network indicating that viewing access to a broadcast program is available via static pricing;
Receiving a purchase request from the mobile device;
Sending decryption key information over the unicast network to the mobile device that will enable the mobile device to access the broadcast program in response to receiving the purchase request; And
And software instructions for performing the steps including determining if a predetermined time threshold has been exceeded before broadcasting the dynamic pricing message. 34. The method of claim 33,
The dynamic price offer is determined to be acceptable if it is greater than the minimum acceptable price,
The minimum acceptable price is less than a static price offer. 34. The method of claim 33,
The dynamic price offer is determined to be acceptable if it is greater than the minimum acceptable price,
The minimum acceptable price is greater than a static price offer. The method of claim 31, wherein
The dynamic pricing is an auction process and the dynamic price offer is a purchase request to access the broadcast program at a current asking price,
The server processor,
Storing an identifier of the mobile device from which the purchase request was received;
Determining whether additional subscriptions are available for purchase;
Closing the auction process if additional subscriptions are not available for purchase;
Determining whether the current quote is equal to a reserve price;
Decreasing the quotation if the current quotation exceeds the minimum auction price;
Closing the auction process if the current bid price is equal to the minimum auction price; And
And software instructions for performing the steps comprising: charging the user account associated with the stored identifier if the auction process is closed prior to the transmission of the decryption keys. The method of claim 31, wherein
The dynamic pricing is an auction process and the dynamic pricing offer is a bid for viewing access to a broadcast content program at a current published quote,
The server processor,
Charging the current quote to a user account prior to sending the decryption keys;
Determining whether time for adjusting the current call price has elapsed;
Determining if the current bid price exceeds a minimum auction price;
Adjusting the current price if the time for adjusting the current price has elapsed and the minimum auction price is not met; And
And software instructions that perform steps that include closing the auction process if the current quote does not exceed the minimum auction price. 39. The method of claim 37,
The server processor,
Software instructions that further perform the step of adjusting the current price by increasing the current price. 39. The method of claim 37,
The server processor,
Software instructions that further perform the step of adjusting the current price by reducing the current price. The method of claim 31, wherein
The dynamic pricing is an auction process and the dynamic price offer is a purchase request to access the broadcast program at a current quote,
The server processor,
Charging the current quote to a user account prior to sending the decryption keys;
Determining whether additional subscriptions for accessing the broadcast program are available at the current quotation;
Determining if the current bid price exceeds a minimum auction price;
Adjusting the current offer price if additional subscriptions for viewing access to the broadcast content are not available at the current offer price and the current offer price exceeds the minimum auction price; And
And software instructions that perform steps that include closing the auction process if the current quote does not exceed the minimum auction price. 41. The method of claim 40,
The server processor,
Software instructions that further perform the step of adjusting the current price by increasing the current price. 41. The method of claim 40,
The server processor,
Software instructions that further perform the step of adjusting the current price by reducing the current price. A mobile device for obtaining viewing access to dynamically priced mobile TV broadcast programs, the mobile device comprising:
A mobile device memory unit; And
A mobile device processor coupled to the mobile device memory unit,
The mobile device processor,
Receiving via the mobile TV broadcast network a broadcast dynamic pricing message indicating that viewing access to the broadcast program is available through dynamic pricing, wherein the broadcast dynamic pricing message is an upper bound on bid. Receiving the broadcasted dynamic pricing message, setting an initial quote that indicates
Displaying the broadcast dynamic pricing message;
Receiving a dynamic price offer entered for viewing access to the broadcast program based on an initial quote that represents an upper limit for the bid;
Transmitting the input dynamic price offer to a server in a mobile TV broadcast network via a unicast network; And
And receiving decryption key information for enabling access to the broadcast program from the server in the mobile TV broadcast network via the unicast network. 44. The method of claim 43,
The mobile device processor,
Receiving a counter offer price from the server in the mobile TV broadcast network;
Displaying the received counter offer price;
Receiving a user input response to the displayed counter offer price; And
And software instructions for performing the steps comprising transmitting a counter for the counter offer price to the server in the mobile TV broadcast network via the unicast network. 45. The method of claim 44,
And if the received user input response indicates acceptance of the counter offer price, the counter for the counter offer price is equal to the counter offer price. 45. The method of claim 44,
And the counter for the counter offer price is lower than the counter offer price if the received user input response indicates a rejection of the counter offer price. &Lt; / RTI &
Broadcasting a dynamic pricing message via a mobile TV broadcast network indicating that viewing access to the broadcast program is available through dynamic pricing, wherein the dynamic pricing message is an upper bound on a bid. Broadcasting the dynamic pricing message, setting an initial quote to indicate a value;
Receiving a dynamic price offer for viewing access to the broadcast program from a mobile device via a unicast network;
Determining whether the dynamic price offer is acceptable based on an initial quote that represents an upper limit for the bid; And
Transmitting decryption key information over the unicast network to the mobile device that will enable the mobile device to access the broadcast program if the dynamic price offer is determined to be acceptable. Computer readable storage medium having stored thereon processor executable software instructions. 49. The method of claim 47,
The computer readable storage medium comprising:
&Lt; / RTI &
And processor executable software instructions configured to further perform sending a counter offer price to the mobile device if the dynamic price offer is determined to be unacceptable. 49. The method of claim 48,
The computer readable storage medium comprising:
&Lt; / RTI &
Broadcasting a static pricing message over the broadcast network indicating that viewing access to a broadcast program is available via static pricing;
Receiving a purchase request from the mobile device;
Sending decryption key information over the unicast network to the mobile device that will enable the mobile device to access the broadcast program in response to receiving the purchase request; And
And processor executable software instructions configured to perform the steps further comprising determining if a predetermined time threshold has been exceeded before broadcasting the dynamic pricing message. The method of claim 49,
The computer readable storage medium comprising:
&Lt; / RTI &
Have processor executable software instructions configured to further perform accepting the dynamic price offer if the dynamic price offer is greater than a minimum acceptable price,
And the minimum acceptable price is less than a static price offer. The method of claim 49,
The computer readable storage medium comprising:
&Lt; / RTI &
Have processor executable software instructions configured to further perform accepting the dynamic price offer if the dynamic price offer is greater than a minimum acceptable price,
And the minimum acceptable price is greater than a static price offer. 49. The method of claim 47,
The dynamic pricing is an auction process and the dynamic price offer is a purchase request to access the broadcast program at a current asking price,
The computer readable storage medium comprising:
&Lt; / RTI &
Storing an identifier of the mobile device from which the purchase request was received;
Determining whether additional subscriptions are available for purchase;
Closing the auction process if additional subscriptions are not available for purchase;
Determining whether the current quote is equal to a reserve price;
Decreasing the current bid price if the current bid price exceeds the minimum auction price;
Closing the auction process if the current bid price is equal to the minimum auction price; And
Computer-readable instructions having processor executable software instructions configured to further perform steps comprising charging the user account associated with the stored identifier if the auction process is closed prior to transmission of the decryption keys. Possible storage medium. 49. The method of claim 47,
The dynamic pricing is an auction process and the dynamic pricing offer is a bid for viewing access to a broadcast content program at a current published quote,
The computer readable storage medium comprising:
&Lt; / RTI &
Charging the current quote to a user account prior to sending the decryption keys;
Determining whether time for adjusting the current call price has elapsed;
Determining if the current bid price exceeds a minimum auction price;
Adjusting the current price if the time for adjusting the current price has elapsed and the minimum auction price is not met; And
And processor executable software instructions configured to further perform steps comprising closing the auction process if the current quotation does not exceed the minimum auction price. 54. The method of claim 53,
The computer readable storage medium comprising:
&Lt; / RTI &
And processor executable software instructions configured to further perform adjusting the current quotation by increasing the current quotation. 54. The method of claim 53,
The computer readable storage medium comprising:
&Lt; / RTI &
And processor executable software instructions configured to further perform the step of adjusting the current quotation by reducing the current quotation. 49. The method of claim 47,
The dynamic pricing is an auction process and the dynamic price offer is a purchase request to access the broadcast program at a current quote,
The computer readable storage medium comprising:
&Lt; / RTI &
Charging the current quote to a user account prior to sending the decryption keys;
Determining whether additional subscriptions for accessing the broadcast program are available at the current quotation;
Determining if the current bid price exceeds a minimum auction price;
Adjusting the current bid price if additional subscriptions for viewing access to broadcast content are not available at the current bid price and the current bid price exceeds the minimum auction price; And
And processor executable software instructions configured to further perform steps comprising closing the auction process if the current quotation does not exceed the minimum auction price. 57. The method of claim 56,
The computer readable storage medium comprising:
&Lt; / RTI &
And processor executable software instructions configured to further perform adjusting the current quotation by increasing the current quotation. 57. The method of claim 56,
The computer readable storage medium comprising:
&Lt; / RTI &
And processor executable software instructions configured to further perform the step of adjusting the current quotation by reducing the current quotation. &Lt; / RTI &
Receiving via the mobile TV broadcast network a broadcasted dynamic pricing message indicating that viewing access to the broadcast program is available through dynamic pricing, the broadcasted dynamic pricing message being bid. Receiving the broadcasted dynamic pricing message, setting an initial quote that represents an upper limit for the &lt; RTI ID = 0.0 &gt;
Displaying the broadcast dynamic pricing message;
Receiving a dynamic price offer entered for viewing access to the broadcast program based on an initial quote that represents an upper limit for the bid;
Transmitting the input dynamic price offer to a server in a mobile TV broadcast network via a unicast network; And
Stored processor executable software instructions configured to perform steps comprising receiving decryption key information to enable access to the broadcast program from the server in the mobile TV broadcast network via the unicast network; Computer-readable storage media. 60. The method of claim 59,
The computer readable storage medium comprising:
&Lt; / RTI &
Receiving a counter offer price from the server in the mobile TV broadcast network;
Displaying the received counter offer price;
Receiving a user input response to the displayed counter offer price; And
And processor executable software instructions configured to perform the steps further comprising: transmitting a counter for the counter offer price to the server in the mobile TV broadcast network via the unicast network.

Images