KR20180129511A - System for dynamic pricing of mobile content - Google Patents

Abstract

A method and a system allow mobile TV broadcast service providers to permit dynamic pricing for access to a broadcast program. A server in a mobile communications TV broadcast network may negotiate a price for accessing a broadcast program with each user through the mobile communications device. The server may receive a request for accessing a broadcast program from the mobile communications device. The server may respond to pricing by accepting a price proposal or by performing a counter proposal until an agreed price is identified. Alternatively, the server may implement any one of a plurality of types of auctions for access to a broadcast program. Similar to a negotiable dynamic pricing method, once a purchase request for viewing access to a broadcast content program is accepted at the current asking price, the mobile TV broadcast service provider may send a decryption key suitable for users to which a proposal or a bidding has been accepted.

Description

SYSTEM FOR DYNAMIC PRICING OF MOBILE CONTENT BACKGROUND OF THE INVENTION [0001]

Wireless communication technology has seen explosive growth over the past several years. This growth is being accelerated by wireless services that provide mobile freedom for the masses and eliminate the limitations of wired communications systems. In addition, increased quality and speed of voice and data communications over wireless media attract additional users. Thus, the popularity of wireless services is expected to continue to grow rapidly.

Wireless communication technologies can broadcast programs to mobile communication users. Mobile communication broadcast users can view mobile communication versions of news, entertainment, sports, etc. using their cell phones or other wireless devices. These broadcast systems are increasing significantly in Internet usage and utility. Presently, mobile TV broadcast service providers set a static price for a viewing access to a broadcast content program. Users choose not to subscribe or subscribe to a broadcast content program based on a static price for viewing access.

Various embodiments herein provide a system that allows a mobile telecommunications service provider to maximize revenue generating opportunity by dynamically pricing a viewing access to a broadcast content program.

The mobile communication service provider may negotiate a viewing access fee with an individual mobile communication device through a server. The server of the mobile communication service provider may request a static fee for the viewing access to the broadcast content. After a predetermined amount of time has passed, the server may broadcast a dynamic pricing message to the plurality of mobile communication devices indicating that a viewing access to the broadcast program is available through dynamic pricing. The server may then negotiate with the mobile communication device until it receives a dynamic price offer from a separate mobile communication device and an interoperable charge is identified. Once the mobile communication device and the server agree with each other for a fee for viewing access, the server sends (or sends to the user a suitable decryption key to provide sufficient viewing access to the mobile communication device to complete viewing for the desired program) .

In another alternative embodiment, a server of a mobile telecommunication TV broadcast service provider may provide various price points that different users may be willing to subscribe to the broadcast content program, so that additional mobile communication devices The auction may be operated.

Figure 1 is an integrated solution architecture.
2 is a block diagram of a mobile communication TV broadcasting system.
3 is a flowchart of a price negotiation method of an embodiment of a mobile communication TV broadcasting system.
4 is a flowchart of a broadcast content price negotiation method.
5 is a flow chart performed by a mobile communication TV broadcast system of a method for transmitting a decryption key suitable for a user's mobile communication device to allow viewing access to a broadcast content program.
6 is a flow chart of a dynamic pricing method for broadcast content.
7 is a block diagram of a mobile communication 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 like parts. References made to specific examples and implementations are for illustrative purposes only and are not intended to limit the scope of the invention or the scope of the claims.

The growing popularity of mobile television (TV) has provided new sources of revenue for mobile TV broadcast service providers that can reach content consumers and 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) do. For example, mobile telecommunication TV broadcast service providers may provide users with a viewing access to a bundled package of individual broadcast content programs or a number of broadcast content programs (e.g., a professional football free voucher) By selling subscriptions, you can generate revenue from their services. By providing the user with a decryption key that is required only when the broadcast content program is encrypted separately and the payout for the subscription is received or otherwise committed, mobile telecommunication TV broadcasters can determine which users are viewing You can control whether you can get access. In conventional systems, the price charged for each subscription is static. The static price may be selected to attract the most potential subscribers while allowing the telecommunications TV broadcast service provider to recover the program's broadcast as well as fixed costs associated with some profits. Choosing a suitable static price may be difficult because a pool of potential subscribers is likely to have a varying degree of interest for broadcast content programs.

The degree of interest of each potential subscriber may be in a broadcast content program and thus the price that each potential subscriber may gladly pay for a 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 to advertise a viewing access to a sporting event prior to actual event and broadcast. 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 surrounding a live event are built, the interest in the event may peak before the broadcast. In addition, the more dynamic the event, the more interested in an event that may exceed expectations (for example, a sports event in which the background stories to the participants increase the interest of the event), and therefore, - It causes difficulty in setting the view price.

A given broadcast content program may be considered a perishable food. For example, a live sport event may be considered as expensive content before broadcasting if the result is unknown. Many potential subscribers may be willing to pay a premium to sign up for an event that occurs in real time or can be viewed. 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, since broadcast will consume a fixed amount of mobile TV broadcast service provider resources (server storage and processing, OA & M and billing, wireless link bandwidth, etc.) Any viewing access subscriptions that are not sold (ie, before broadcasting) represent lost revenue opportunities.

In some circumstances, the broadcast network may be treated like an appendix to a stadium place. In this situation, the number of seats for broadcast viewing may be limited as in the stadium due to the contract with the event organizer. In this scenario, the traditional method may be used to obtain the best selling price for a limited number of sheets.

For this reason, it would be advantageous for mobile telecommunications service providers to implement a form of dynamic pricing for viewing access to at least some of their broadcast content programs. The dynamic pricing method allows the mobile TV broadcaster to maximize the revenue generating opportunities for some programming by allowing the consumer to influence the pricing that is appropriate for viewing access to broadcast content programs You may.

Dynamic pricing may be implemented, for example, by allowing a user to negotiate a price for a viewing access with a mobile telecommunications service provider. In this way, a mobile telecommunication TV broadcast service provider may maximize the number of subscribers to a particular program and the level of interest for its respective changing program by appealing to various subscribers. The mobile TV provider may also maximize the price received for the viewing access by still allowing subscribers who are most interested in the program to pay more while still attracting subscribers with minimal interest. Potential subscribers may be allowed to suggest a price they are willing to pay for a viewing access to the broadcast content program. The mobile TV broadcast service provider may then accept or reject such a proposal. In addition, the mobile communication TV broadcast service provider may be configured to provide a counter offer.

Currently, the OMA BCAST (Open Mobile Alliance Broadcast Working Group) specification defines a set of standardized service delivery messages (e.g., for subscription / non-subscription, price survey, account information retrieval, etc.). The OMA BCAST Service Guide (SG) specification also indicates when the price associated with a particular broadcast content is not in the "purchase data" portion of the guide, meaning that the purchase price of the broadcast content is negotiable with the user in a future purchase transaction do. The various embodiments disclosed herein provide a system and method for supporting a dynamic pricing model to broadcast mobile communication TV content, such as negotiable pricing methods.

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

A number of different mobile communication TV layer technologies and related standards are available or are considered in the future, all of which may implement and benefit from various embodiments. These standards include the Open Mobile Alliance Mobile Broadcast Services Enabler Suite (OMA BCAST), MediaFLO, Digital Video Broadcast IP Datacasting (DVB-IPDC), and China Multimedia Mobile Broadcasting (CMMB). While broadcast formats and terms may vary between different mobile TV service standards, they all require the mobile communication device to receive selected content and send metadata to the users to inform them of the programs and content available for viewing or downloading . In order to avoid confusion with respect to particular broadcast standards, general term content flows, overhead flows, and metadata messages are used herein to describe various embodiments.

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

A mobile telecommunication TV broadcast service is a service that provides a mobile communication device with a plurality of broadcast transmissions that are separate from some of the broadcast transmissions (referred to herein as " overhead stream " or " To broadcast the information about the program and content to be broadcast in the future through some of the dedicated broadcast transmissions to return overhead information. The mobile communication device may also process this metadata to provide the electronic viewing guide to the user. These electronic viewing guides, known in some mobile communication 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.

The 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 communication TV broadcast signal for conveying overhead information such as program and content metadata. In contrast to this overhead flow, programs and content are typically broadcast using high bandwidth portions of a broadcast signal, referred to collectively herein as " content flow ".

Typically, the mobile telecommunication TV broadcast network 1 comprises a plurality of broadcast transmitters 2 controlled by a mobile telecommunication network control center 4. The mobile telecommunication TV broadcast network 1 broadcasts content from broadcast transmitters 2 such as mobile telecommunication broadcast transmissions 3 for reception by the mobile telecommunication device 10. In the mobile communication network control center 4, the scheduling of the content broadcasting, the generation of the electronic service guide and the other metadata related to the content broadcasting, and the generation of the metadata for broadcasting through the overhead flow of the mobile communication TV broadcasting network 1 There is one or more content management servers 6 that may be configured to manage the generation of data messages. One or more content management servers 6 may also include a connection to an external network such as the Internet 7 and via the Internet the content management server 6 may receive a content feed from the content provider server 8. [ Lt; / RTI > One or more content management servers 6 may be configured in accordance with various embodiments to receive content from the content provider server 8 and determine information about the received content, such as a fixed fee for viewing access to the sanitized content It is possible. The content management server 6 may also take on the task of receiving a broadcast content program request. Such a request may be made by the user in association with either the static pricing model or the dynamic pricing model. In these other embodiments, a further subscription management server (not shown) may be provided in association with the content management server 6. While the content management server 6 may be tasked with all content management functions, the subscription management server may take on the task of receiving a content program request. Such a request may be made by the user in connection with either the static pricing model or the dynamic pricing model.

A viewing request may also be made from the secondary user terminal 11. For example, a user may want to schedule a view of a program on the mobile communication 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. When the price negotiation is successfully completed and the viewing request is accepted, the program response manager 9 may instruct the subscription management center 12 to send the encryption key necessary for the actual viewing to the mobile communication device 10. [

Typically, a mobile telecommunications service provider receives different content sources and various different programs and content from a content provider. A mobile TV broadcast service provider typically stores content on a server, schedules a broadcast window for each content, and then broadcasts the content in batches. In order to allow the mobile communication device to receive the content, the mobile communication TV broadcast service provider server sends the broadcast message to the mobile communication device via an overhead flow, which informs the mobile communication device of when each program or content is to be transmitted, Lt; / RTI > message. In the case of a live television event (e.g., a sporting event, a concert), the content is transcoded before broadcasting through streaming. This may result in a small latency due to transcoding. Typically, a mobile communication TV broadcast service provider may know when each program or content is to be transmitted and the broadcast address to which the transmission is to be made, because the mobile communication TV broadcast service provider may be well known prior to the live television event when a live event occurs It may still generate a metadata message for transmission via an overhead flow notifying the mobile communication device. The mobile communication device may utilize the information in the metadata message to determine if any content has been selected by the user for stream reception and file download and in this case to view the network address and broadcast transmission for the selected content to be received and determines the time for tune in.

The mobile communication TV broadcast network 1 may receive content (e.g., a television program website, a serial data feed, etc.) from a plurality of content sources 8a, 8b. Such content may be provided to the content management server 6 within the mobile communication TV broadcast network 1 via the data network 20. [ The content management server 6 may store such content in a database and schedule broadcast content. In the scheduling of broadcast content, the content management server 6 decides when and on what network address what will be broadcast. As part of the scheduling, the content management server 6 may format the content into a content package (CP). The content management server 6 may also determine information about the content, such as the title of the information, its source, the nature of the information, its age or date / time of creation, and the pricing of the viewing access to the content. The content management 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 the content is scheduled for broadcast, the content management server 6 may provide the content package to the content broadcasting system 4 in the network data flow 22. The service guide may also be provided in the network data flow 24. These data flows are then processed by the content broadcast system 4 with a multiplex broadcast waveform that is broadcast live by a network transmitter 2, such as a broadcast transmission.

Within the broadcast transmission there may be a number of different content flows (CF) 26 that are data packets carrying broadcast content in addition to a service guide flow 28 that includes a data packet carrying a content packet description. The mobile communication device 10 may receive broadcast transmissions and may separately process the content flow (s) 26 and the service guide flow 28.

To facilitate dynamic pricing, each user's mobile communication device 10 may communicate with the program bidding manager 9 via a unicast network 5. The program response manager 9 may be a software module operating in the content management server 6 or may be software operating on a separate server communicating directly with the content management server 6. [ The program bidding manager 9 module in the content management server 6 is responsible for sending the dynamic price offer, acceptance and counter offer to each individual mobile communications device 10 and for offering dynamic price offer, acceptance and counter offer from the mobile communications device You may be responsible for receiving.

The communication between the program response manager 9 module and the mobile communication device 10 may be via a bi-directional communication link on the unicast network 5. [ The bi-directional communication link may be configured to communicate voice traffic and / or data traffic between various devices including each of the mobile communication devices 10. A bidirectional link as utilized by various embodiments includes, but is not limited to, a wireless link or even a particular telephony technology, including one or more of Ethernet, a telephone (e.g., POTS), cable, power line, and fiber optic system (CDMA or CDMA 2000) communication system, a frequency division multiple access (FDMA) system, a GSM / GPRS (Enhanced Data GSM) / EDGE (1xEV-DO or! xEV-DO Gold Multicast) systems such as Time Division Multiple Access (TDMA) systems, such as the TETRA (Terrestrial Trunked Radio) mobile telecommunications system, Wideband Code Division Multiple Access (WCDMA) System, 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 management server 6 in the mobile communication TV broadcast network 1. [ The service guide includes a data model that models services, schedules, content, related purchasing and supply data, fragmented access, and interactive data. The service guide may be as defined in the OMATS-BCAST_Services-V1_0 specification from OMA.

The price negotiation process may be performed by a content management server 6 having a module in the content management server 6 or a program bidding manager 9 operating as a separate server communicating with the content management server 6. [ For brevity, the program response manager 9 will be described as a module in the content management server 6. The operation of the program response manager 9 will be referred to as being performed by the content management server 6. However, these operations may be performed by a different server in or connected to the mobile communication TV broadcast system.

When the service guide is received, the user may decide that the user is interested in viewing a particular broadcast content program. In the dynamic pricing operation, at step 50, the content management server 6 may receive a user dynamic price offer for the broadcast program. The content management server 6 may evaluate the user's price offer and may determine in decision 51 whether the price offer is acceptable or not. This may be accomplished, for example, by comparing the proposed price to a predetermined threshold stored in memory, or by analyzing the proposed price using an algorithm for predicting the maximum revenue price. If the price offer is acceptable (i. E., Decision 51 = YES), the content management server 6 may initiate the process at step 55 to send a message to the user that the price offer is acceptable. The content management server 6 may then send a decryption key to the user to provide the user with a viewing access to the broadcast content program at step 56. [

However, if the price offer is not acceptable, the content management server 6 at step 52 may send a counter offer to the user via the bi-directional link on the unicast network 5. The content management server 6 then waits for the user's response to the counter suggestion at step 53. [ When the counter proposal is accepted by the user, the user's mobile communication device 10 may transmit an acceptance message to the content management server 6. [ When the mobile communication device 10 receives the user's input to accept the counter offer, the mobile communication device 10 generates a new dynamic price offer identifying the price offer contained in the counter offer of the content management server 6 And may also transmit. Upon receipt of the new dynamic price offer, the content management server 6 will accept the new dynamic price offer as including a previously acceptable price offer. Alternatively, the mobile communication device 10 may generate an indication that the counter offer is acceptable and send it to the content management server 6.

Any of a number of negotiation algorithms may be used by the content management server 6 to enable dynamic price negotiation. For example, a minimum acceptable price of a viewing access to a broadcast content program may be established. If the price suggested by the user is below the minimum acceptable price, the difference between the minimum acceptable price and the price suggested by the user may be calculated. The content management server 6 may generate and transmit a counter suggested price so that the difference between the counter suggested 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 manner, the content management server 6 may continue to generate and transmit counter suggestions until some price that is greater than the minimum acceptable price or the minimum acceptable price is suggested and / or accepted by the user .

As an example of an operating method embodiment, the pay-per-view program may be a live broadcast of a sporting event. The content management server 6 may generate a content packet description (CPD) describing the broadcast content program, including various information including a static price to be granted a viewing access. These CPDs may be broadcast to users in step 201 in the form of a service guide. The content management server 6 may receive a user request for a broadcast content program at a static price.

At some time before the actual broadcast time of the sporting event, the mobile TV broadcast service provider may choose to initiate the dynamic pricing mode. Thus, content management server 6 may periodically determine at decision 202 whether the time remaining before the actual broadcast time exceeds some predetermined threshold. If the time for broadcasting exceeds a predetermined threshold (i.e., decision 202 = NO), the content management server 6 continues to insert the CPD into the service guide at a static price. However, if the time to actually broadcast is less than a predetermined threshold (i.e., decision 202 = YES), the content management server 6 may change the CPD to remove the static price for the broadcast content program from the service guide at 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 a dynamic pricing mode and accepting negotiable price offers from users.

The content management server 6 sets the negotiable flag to " 1 " to enable the dynamic pricing process, whereby the content management server 6 (or the price bid manager 9) Processing may allow the user to accept negotiable price suggestions. The content management server 6 may also set a minimum acceptable price for a viewing access to the broadcast content program at step 205. [ The mobile telecommunication TV broadcast service provider may choose to perform the dynamic price negotiation process by a predetermined predetermined time. This predetermined time may be before the start of the broadcast, but may extend until the end of the broadcast. For example, users may be allowed to negotiate a price to access broadcast content until the start of a scheduled broadcast content program.

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 to negotiate the price has not expired (i.e., decision 207 = NO), the content management server 6 may continue to perform the broadcast content price negotiation process at step 206. However, if the time for negotiation has expired (i.e., decision 207 = YES), the content management server 6 resets the negotiable flag to " 0 " at step 208, The broadcast content information may be inserted into the service guide for the service.

The content management server 6 may receive a broadcast content viewing access request from the users at step 210. [ In some cases, users may send a request for viewing access before the content management server 6 operates in the dynamic pricing mode. In this case, the user requests a viewing access to the broadcast content program for the static price. Therefore, upon receipt of the viewing access request of the user, the content management server 6 judges whether or not the negotiable flag in the decision 211 is set to " 1 " indicating that the content management server 6 is in the dynamic pricing mode, Can be checked. If the negotiable flag is not set to " 1 ", then the dynamic pricing operation cycle has not yet begun, and the broadcast content viewing access is only available to users for static prices. Users may pre-pay, receive and store tokens on their mobile communication device 10, which may be exchanged for viewing access to the broadcast program. Some broadcast programs may require submission of one or more tokens before the viewing access is approved. In this way, money is no longer exchanged for viewing access. If the token or payout has not been received (i.e., decision 217 = NO), content management server 6 may continue to wait for confirmation of token / payout receipt at decision 217. Once the token or payout is received (decision 217 = YES), the content management server 6 (or a separate billing server communicating with the content management server 6) may withdraw the payout from the user account at step 218, (S).

If the negotiable flag is set to " 1 " (i.e., decision 211 = YES), the content management server 6 proceeds to step 212 (via the program bid manager 9) . The content management server 6 then proceeds to a step 213 in which the content management server 6 determines if the analyzed price offered by the user is a minimum acceptable price (i.e., decision 213 = YES) At 219, the user may accept the price offer, accept the payment, and send the appropriate decryption key. If the analyzed price offer is less than the minimum acceptable price (i.e., decision 213 = no), the content management server 6 may generate and transmit a counter offer containing the suggested price for viewing access at step 214 . As discussed above, any of a variety of negotiation know now may be implemented by the content management server 6 to generate a suitable counter suggestion. Once the counter offer is generated and sent back to the user on the bi-directional link in the unicast network 5, the content management server 6 may wait for the acceptance, rejection, or counter of the user for the counter offer in step 215.

Various mechanisms may be used to link decryption keys for subscription purchases. Typically, a mobile communication broadcast service is a unicast communication network, such as a consumer's cellular telephone data service, to communicate subscription messages to / from a particular consumer mobile communication device, May also be used. The decryption key may be configured to expire after a predetermined amount of time in order not only to enable pay-per-view (pager-play) type services, but also to limit the economic impact of the decryption key falling into the public domain have.

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

The user may participate in the negotiation process with the mobile communication TV broadcast service provider through the content management server 6 at steps 206 and 306. [ Once the negotiation has been successfully completed, the content management server 6 may send a message to the user's mobile communication device 10 indicating a successful negotiation at step 219. [ The content management server 6 may also send a message to the content provider server 8 informing the content provider server of the identity of the mobile communication device 10 of the user who has successfully negotiated and successfully negotiated in step 219. [ A successful negotiation message may be received by the user's mobile communication device 10 at step 319 as well as by the content provider server 8 at step 119. [ Upon receipt of a successful negotiation message, the content provider server 8 may initiate a process for providing the user with a suitable decryption key to view the purchased broadcast program.

In response to the received successful negotiation message (step 119), the broadcast content provider 8 generates a long decryption key message, e.g., LTKM, at step 123 for use by the user's mobile communication device 10, (6). The LTKM may include conditions and terms that the mobile communication device 10 can decrypt the TEK within the STKM to decrypt and display the contents of the purchased program. The LTKM sent to the content management server 6 may also include a restricted access key to allow the user to view the broadcast program only for a 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 sequential sequence of encrypted broadcast content as well as the STKM in step 125. The content management server 6 may receive and transmit the LTKM in steps 223 and 224. The mobile communication device 10 receives the LTKM via the unicast network 5 in step 324. [ The mobile communication device also receives the encrypted content stream and the STKM stream over the broadcast network 3 in step 325. The mobile communication device 10 may use the LTKM to decrypt the TEK contained in the STKM stream. The TEK is then used to decrypt the purchased broadcast content. If the broadcast content is decrypted, the mobile communication device may display the content to the user for viewing in step 326.

The user may desire to pre-order a program for broadcast reception on the mobile communication device from the remote secondary user terminal 11. In the process / message flow 700, the broadcast content price is negotiated between the secondary user terminal 11 and the content management server 6 at step 206, 306. Upon completion of the successful negotiation, the content management server 6 may send an indication of a successful negotiation, which may be received by the content provider 8 (step 119) as well as the secondary user terminal 11 (step 319) (Step 219). As described above, the broadcast content provider 8 may generate and transmit the long-term decryption key message, e.g., LTKM, to the content management server 6 in step 123 for use by the user's mobile communication device 10. [ The LTKM sent to the content management server 6 may also allow the user to view the broadcast program only for a limited time period, including a restricted access key.

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

In step 201, the content management server 6 may transmit a service guide including information on various broadcast content programs. A static price to obtain a viewing access to the broadcast content may be included with this information. Through the mobile communication TV broadcast transmission (3), users may receive a service guide with a fixed price on the mobile communication device (10) at step 301.

When the content management server 6 transmits the service guide, the content management server may periodically monitor the remaining time before the broadcast time for the broadcast content program. If the remaining time before the broadcast is less than the predetermined threshold (i.e., decision 202 = NO), the content management server 6 may continue to transmit the service guide including the static price for the broadcast content program at step 201. [ Once the remaining time before the broadcast is less than a predetermined threshold (i.e., decision 202 = YES), the content management server 6 may transmit the service guide update without pricing information regarding the specific broadcast content program at step 203. [

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

The content management server 6 receives the user's request at step 210 and performs steps 211-220 as described above. When the content management server 6 answers the counter suggestion at step 214, the user's mobile communication device 10 may receive the counter suggestion at step 314 and display the counter suggestion at step 315 to the user. The user may then answer the counter suggestion by accepting the counter suggestion, suggesting a counter to the counter suggestion, or rejecting the suggestion. The mobile communication device 10 may receive a user entered response at step 316 and may determine at decision 317 whether the user accepts the offer. If the user indicates that the counter offer is acceptable (i.e., decision 317 = YES), the mobile communication device 10 may send a counter offer to the content management server 6 as a new suggested price in step 318. Since the new proposed price is already an acceptable price to the content management server 6, the user's counter offer would be acceptable to the content management server 6. As a result, when the counter suggestion is received in step 210 and analyzed in step 211, the content management server 6 will accept the counter to allow viewing access in steps 217-220 and sequentially transmit the appropriate decryption key . Alternatively, the mobile communication device 10 may send a message to the content management server 6 that accepts the counter offer.

Alternatively, the user may choose to counter the counter offer. If the mobile communication device 10 determines from the user input that the counter of the content management server 6 is not acceptable (i. E., Decision 317 = no), the mobile communication device 10 may reject the counter offer, The user may be prompted to indicate whether the user wants to do the counter. The mobile communication device 10 may receive user input and may determine at decision 230 whether the user wishes to accept or reject the counter suggestion. If the mobile communication device 10 determines that the user rejects the counter suggestion (i.e., decision 230 = NO), then the mobile communication device 10, in step 322, affects the content management server 6 over the unicast network The broadcast request may be interrupted by sending a message. If the mobile communication device 10 determines that the user desires to counter the counter offer (i.e., decision 320 = YES), the mobile communication device sends a counter offer price to the counter offer received from the content management server 6, . The mobile communication device 10 receives the counter price from the user and sends the information to the content management server 6 in a similar manner to the original request with the new proposed price at step 321. [ Upon receipt of the counter for the counter suggestion at step 210, the content management server 6 may evaluate the counter for the counter suggestion and accept or counter the most recently received counter suggestion. This process may continue until mutual agreement is reached or until the user chooses to discontinue the negotiation. In some embodiments, the process may be allowed to undertake a limited number of iterations to minimize consumption of network resources (e.g., unicast network bandwidth).

One instantiation of fragment A refers to the c to d instantiation of fragment B. If c = d, then d is omitted. Thus, if c> 0 and fragment A is present, there may also be a maximum d instancing of fragment B, although at least c instancing of fragment B must also be present. Conversely, one instance of fragment B is referenced by the a to b instantiation of fragment A. If a = b, b is omitted. An arrow link from fragment A pointing 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 any other 'Purchase Item'. An 'access' fragment may have a connection to either a 'service' fragment or a 'schedule' fragment.

Between the 'schedule' fragment and the 'interactive data' fragment; And between the 'approach' fragment and the 'preview data' fragment. The reference arrow from the 'schedule' fragment to the 'interactive data' fragment declares the distribution schedule of the interactive media documents returned in the file stream (referenced by the 'interactive data' fragment). A reference arrow from a 'bidirectional data' fragment to a 'schedule' fragment declares a 'schedule' fragment to which the 'bidirectional data' fragment is associated. A reference arrow from an 'access' fragment to a 'preview data' fragment represents a service-by-service switching preview information for access. The 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 aggregate level of content items including broadcast services. A service may be delivered to a user using multiple access means, e.g., a broadcast channel and a reciprocal channel. The service may target a given user group or geographic area. Depending on the type of service, it may have a mutual part (s), a broadcast-only part (s), or both.

The service may further include components directly related to user acquisition, e.g., purchase or subscription information, that are not directly related to the content but relate to the functionality of the service. As part of the service guide, the 'service' fragment forms the central hub referred to by other fragments including the 'access', 'schedule', 'content' and 'purchase item' fragments. Also, a 'service' fragment may refer to a 'preview data' fragment. The 'preview data' fragment may not be referenced by any of these fragments and may be referenced by some of each of these fragments.

The 'schedule' fragment defines a time frame in which the associated content items are available for streaming, downloading and / or rendering. This fragment refers to the 'service' fragment. Also, 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 of interactive media documents associated with the service, . On the other hand, if the 'schedule' grammar does not refer to any 'content' fragment (s) or 'bidirectional data' fragment (s), it defines the time frame of unbinded service availability.

The 'content' fragment provides a detailed description of a particular item of content. In addition to defining the type, description, and language of the content, information on the genre and parent rating as well as the target user group or geographic area may be provided.

The 'content' fragment may be referred to by a schedule, a purchase item or an 'interactive data' fragment. Quot; preview data " fragment or a " service " fragment.

The 'access' fragment describes how the service may be accessed during the lifetime of the service. This fragment contains or references session description information and indicates the delivery method. One or more 'access' fragments may refer to a 'service' fragment that suggests alternate approaches for accessing or interacts with the associated service.

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

A 'session description' is a service guide fragment that provides session information for access to a service or item of content. In addition, the session description may provide supplemental descriptive information used in the associated delivery procedures.

The " purchase item " fragment represents one or more service groups (i.e., service bundles) or one or more items of content that are offered to the end user free of charge for subscription and / or purchase.

The 'purchase data' fragment may collect information about one or more purchase channels and may be associated with preview data specific to a particular service or service bundle. Service, bundle of services, or pricing of the item of content. Information about the promotional activity may also be included in this fragment.

The " purchase channel " fragment carries information about an entity, i.e., a content provider or a content providing website, from which access to a particular service, service bundle or item of content and / May be obtained as defined in the fragment. The purchase channel is associated with one or more mobile communication TV service providers. The mobile communication device is also only authorized to access a particular purchase channel when associated with a mobile communication TV service provider associated with the purchase channel.

Multiple purchase channels may be associated with a single 'purchase data' fragment. In other words, the same pricing term for subscribing to a program may be proposed by different mobile TV providers at the same time. A given end-user may have a " preferred " purchase channel (e.g., his / her mobile proposer) in which all purchase requisitions are directed. The preferred purchase channel may be the only channel that the end-user is allowed to use.

The 'preview data' fragment includes information used by the mobile communication device to present the service or content outline to users, so that users can have a general idea of what service or content they are about. The 'preview data' fragment may include simple text, a fixed image (e.g., a logo), a short video clip, or may refer to other services that may be a low bit rate version for the main service. The 'service', 'content', 'purchase data', 'access' and 'schedule' fragments may refer to a 'preview data' fragment.

The interactive data includes information used by the mobile communication device to suggest interactive services to a user associated with the broadcast content. These interactive services may allow a user to vote for a TV show or acquire content related to broadcast content. An '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 referenced by a 'schedule' fragment.

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

The service request is sent to the content management server 6 by the mobile communication device 10 to request the 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 differs from the price calculated by the content management server 6 for one or more of the purchase items included in the request, the content management server 6 sends a pricing information response message You can also respond. In addition, if the price is not specified for one or more of the purchased items of the requested message, the content management server 6 may respond to the pricing information response message. Otherwise, the content management 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 negotiable elements. If there is no 'price' in this pricing information response message, this element indicates that the purchase price is negotiable in a subsequent purchase transaction.

The purchase data fragment is assigned to [BCASTlO-SG] which contains the price associated with the information on the requested purchase item (s). A fragment that is either a 'purchase data reference' fragment or a 'purchase data fragment' fragment, but not both, may be illustrated as a 'pricing information response' message.

The service request message may include the following elements: a user ID; Device ID; Service encryption protocol; Purchase item; And Drm profile specific parts or smart card profile specific parts. 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 a message may be used to request delivery of SEK (s) / PEK (s) And the like.

The purchase item element includes a list of items the user wants to order, a price, and a list of services the user wants to subscribe to. Purchase items include purchase data reference, price, offer price, and service element. The proposed price element represents a price offer by the user for purchase of the referenced purchase item. Its (optional) presence may be triggered by any one of two events.

The service response message may be transmitted from the content management server 6 to the mobile communication device in response to a request to subscribe to the service request message. This message is applicable to both the DRM profile and the smart card profile. The service response message includes a purchase item element that describes the result of a request message to subscribe to or purchase a purchase item. In the DRM profile, if the subscription or purchase is successful, the right end time of the purchased item will be expressed. The purchase item element includes an Acceptability element in which the service request includes the element 'offer price' and indicates whether or not the price offer is accepted by the content management server 6. 'Acceptability' = true or 1 indicates that the proposed price from the user for purchase of this purchase item, as contained in the 'service request' message, is accepted by the content management server 6. 'Acceptability' = false or 0 indicates that the proposed price from the user for purchase of this purchase item as contained in the 'service request' message is not accepted by the content management server 6. The acceptability element includes a counter price element indicating whether ' acceptability ' = false or 0, and the presence of this element indicates that the counter suggested price from the content management server 6 for this purchase item is accepted.

Various auctions may be implemented to arrive at an acceptable price for viewing a broadcast program, rather than negotiating the price of a viewing access or accepting a conventional static pricing. The quotation is lowered at intervals of a predetermined time. As the price is lowered, users may send a purchase request to the content management server 6 indicating that they are willing to purchase the broadcast content program at the current quotation. The quotation may be lowered continuously until the maximum number of proposed subscriptions through the auction is reached or a predetermined minimum reserve price is reached. Once the end point is reached, the final quotation may be billed to all users to whom the purchase request is sent, and in turn, the viewing privilege may be received. View access is granted only to users who have submitted a purchase request. Thus, if the maximum number of subscriptions are acquired before the desired price of the potential users is known, it may not be possible for potential users who have delayed the bid submission to view the program to desire a lower price. Thus, users interested in a broadcast program are motivated to accept higher quotes to ensure that they can purchase viewing privileges. Similarly, users who initially submitted the bidding should be at risk of initially filling the maximum number of subscriptions. As a result, these users may pay more for broadcast content programs than originally intended.

Other auction variants may be implemented. For example, rather than having all the bidder pay the final price, each bidder may be required to pay the purchase price. For example, a mobile telecommunications service provider may notify all potential tenderers that only a limited number of subscriptions will be available for auction. In order to ensure that they enable them to obtain a viewing approach, the tenderers may choose to submit the tender early on at a higher price. Those biders who want to ensure a viewing approach in contrast to those who are willing to risk the risk of failing to obtain a viewing access later may be required to initially pay higher prices.

As described above, the content management server 6 creates 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 management server 6 may insert broadcast content information into the service guide indicating that the particular broadcast content program is available via auction at step 225. [ CPDs may also provide users (potential bidder) with specific rules that govern the auction. For example, the content management server 6 may determine that users must submit a bid to obtain a viewing access, that the auction may be terminated when the number of accepted bids exceeds a certain threshold or the minimum auction price is met , That the quotation will be periodically lowered, and that the price charged to each user may be determined by the final request response accepted at the auction.

After the rules of the auction are sufficiently broadcasted to the users, the content management server 6 may set the initial call price at step 230. The content manager may also set the bid counter to zero at step 235. At this time, the content management server 6 may start an auction and start receiving purchase requisitions or responses from users at step 240. When each of the bid or purchase requests is received, the content management server 6 records and stores an identifier for the mobile communication device 10 of the user who performs the purchase request or broadcast content program request response in step 245. [ The content management server 6 then increments the bid counter at step 250 and determines at decision 255 whether 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 (i.e., decision 255 = YES), the content management server 6 may close the auction at step 275 and record the final bid price. Once the auction is closed, the content management server 6 retrieves the payout in the amount of the final quotation from each user account associated with the identifier stored in step 245 either directly in step 218 or via a billing server (not shown) You can get it.

If the number of bids is not equal to the maximum number of available subscriptions (i.e., decision 255 = no), content management server 6 may determine at decision 260 whether more bidding or purchase requests are being received. If more bids are being received (i.e., decision 260 = YES), content management server 6 may return to step 240 to continue receiving bidding or purchase requests from other user mobile communication devices. If no further bidding is received (i.e., decision 260 = NO), content management server 6 may determine at decision 265 whether a minimum auction price has been reached. If the minimum auction price has been reached (i.e., decision 265 = YES), content management server 6 may close the auction at step 275 and perform steps 218-220 as described above. However, if the minimum auction price has not been reached (i.e., decision 265 = NO), content management server 6 may lower the quotation at step 270 and return to step 240 to send additional bid or purchase requests from users .

In some cases, such as when program broadcast time is approaching, the price that a user is willing to pay for a viewing access may increase. Alternatively, after the broadcast content program is started and broadcast, the price that the user is willing to pay for viewing access may decrease.

Once the auction rules are sufficiently broadcasted to the users to inform the users of the auction and its rules, the content management server 6 may set the initial quotation in step 230. Once the initial quotation has been set, an auction may be initiated and the content management server 6 may receive a purchase request or broadcast content request response at the current call price in step 231. Content management server 6 may periodically determine at decision 232 whether it is time to adjust the call. If the time for adjusting the quotation has not yet elapsed (i.e., decision 232 = NO), the content management server 6 returns to step 231 and continues to receive the broadcast content program request response or purchase request. If the time for adjusting the price has elapsed (i.e., decision 232 = YES), the content management server 6 determines at decision 233 whether a further suggested call level is available. If no further offered call level is available (i.e., decision 233 = NO), the content management server 6 closes the auction at step 275 and may no longer accept the program purchase request. If a further suggested call level is available (i.e., decision 233 = YES), the content management server 6 may increase (or decrease) the quotation for the broadcast program at step 234. Once the quotation has been adjusted, the content management server 6 may return to step 231 to accept the purchase request or additional user bid at the adjusted call price level.

In method 1200, the content management server 6 informs the users of the auction rules through the service guide in steps 225-240, sets the initial call price, sets the response counter to zero (0) And begins to receive the response. The content management server 6 receives the payout as in the above-described steps 217-220, informs the user of the successful purchase, and transmits a decryption key suitable for the viewing access. As each of the bid or purchase requests proceeds and the decryption key is transmitted (step 220), the bid counter is incremented in step 237. The content management server 6 then determines in step 238 if the maximum number of subscriptions available for the current quotation has been sold. If the maximum number of subscriptions to the current call level has not yet been sold (i.e., decision 238 = NO), the content management server 6 will continue to receive bid or purchase requests at the current quotation by returning to step 240. If a further suggested call level is available (i.e., decision 233 = YES), the content management server 6 may increase (or decrease) the quotation for the broadcast content in step 234. Once the quotation has been adjusted, the content management server 6 may return to step 235 to reset the counter that counts the number of subscriptions sold at the particular call.

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

One exemplary mobile communication device 10 may include an internal memory 192, a display 193, and a processor 191 coupled to the speaker 199. The mobile communication device 10 may also have a cellular telephone transceiver 195 coupled to the processor 191 and / or an antenna 194 for transmitting and receiving electromagnetic radiation coupled to the wireless data link. In some implementations, processor 191 and portions of memory 192 and transceiver 195 used in cellular telephony communications are collectively referred to as an air interface, since they provide a data interface over a wireless data link. Typically, mobile communication devices also include a keypad 196 or mini keyboard, and menu selection buttons or locker switches 197 to receive user inputs.

In addition, many of the above-described embodiments may be implemented with any of a variety of general purpose computers or remote server devices, such as server 2400. [ Typically, such a server 2400 includes a processor 2201 coupled to volatile memory 2402 and a mass nonvolatile memory such as disk drive 2403. In addition, the server 210 may include a compact disk (CD) drive 2406 coupled to the processor 2401 and / or a floppy disk drive. In addition, the server 210 may include network access ports 2404 coupled to the processor 2401 for communicating with the network 2405, such as the Internet.

Claims (7)

A server memory unit; And
And a server processor coupled to the server memory unit,
The server processor,
Broadcasting a dynamic pricing message through a mobile communication TV broadcast network to indicate that a viewing access to the broadcast program is available through dynamic pricing;
Receiving a dynamic price offer for a viewing access to the broadcast program from a mobile communication device over a unicast network and determining if it is acceptable;
Transmitting decryption key information to the mobile communication device via the unicast network to enable the mobile communication device to access the broadcast program if the dynamic price offer is determined to be acceptable; And
And transmitting the counter suggested price to the mobile communication device prior to transmitting the decryption key information to the mobile communication device via the unicast network. The method according to claim 1,
The server processor,
And sending a counter suggested price to the mobile communication device when the dynamic price offer is determined to be unacceptable. 3. The method of claim 2,
The server processor,
Broadcasting a static pricing message through the broadcast network indicating that a viewing access to the broadcast program is available through static pricing;
Receiving a purchase request from the mobile communication device;
Transmitting decryption key information to the mobile communication device via the unicast network to enable the mobile communication device to access the broadcast program in response to receiving the purchase request; And
And determining whether a predetermined time threshold has been exceeded before broadcasting the dynamic pricing message. The method of claim 3,
The dynamic price offer is determined to be acceptable if it is greater than a minimum acceptable price,
Wherein the minimum acceptable price is less than a static price offer. The method of claim 3,
The dynamic price offer is determined to be acceptable if it is greater than a minimum acceptable price,
Wherein said minimum acceptable price is greater than a static price offer. The method according to claim 1,
Wherein the dynamic pricing is an auction process and the dynamic price offer is a purchase request for accessing the broadcast program at a current quotation,
The server processor,
Storing an identifier of the mobile communication device in which the purchase request is received;
Determining if additional subscriptions are available for purchase;
Closing the auction process if additional subscriptions are not available for purchase;
Determining whether the current quotation is equal to a minimum auction 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 billing the current quotation to a user account associated with the stored identifier if the auction process is closed before sending the decryption keys. The method according to claim 1,
Wherein the dynamic pricing is an auction process and the dynamic price offer is a bid for a viewing access to a broadcast content program at the current published quotation,
The server processor,
Billing the user account for the current quotation before sending the decryption keys;
Determining whether a time for adjusting the current quotation has elapsed;
Determining whether the current quotation exceeds a minimum auction price;
Adjusting the current quotation if the time for adjusting the current quotation has elapsed and the minimum auction price has not been met; And
And closing the auction process if the current bid price does not exceed the minimum auction price.

Images