Patent Application
20060111985
The present invention generally relates to the field of content and more particularly relates to systems, methods, and apparatus for content storage, auction, and management.
Users have access to devices that have an ever increasing range of functionality to playback content at a client device. One such example is digital video recorder (DVR) functionality. For instance, a DVR may include a hard disk memory. Due to the size of the memory, users of the DVR are able to record content. DVRs also offer “trick modes”, such as the ability to pause content that is currently being broadcast and allows users to watch the content, while still in progress, from the point it was paused. For example, the DVR may play back the content from disk memory, starting at the pause event, while continuing to record the currently-broadcast content in the disk memory. Additionally, the DVR may support other trick modes, such as rewinding, fast forwarding, slow motion playback, and the like.
Even though the memory on the DVR may be utilized to record a large amount of content, the DVR may still include unused storage space. The unused storage space may be available for a variety of reasons. For instance, a provider of the DVR may retain a portion of the storage device to push content to the storage device as desired by the provider, such as to provide locally stored video-on-demand (VOD) which is available for purchase by the user of the DVR. In another instance, the DVR may include storage space in the memory that is not currently being used to store television programs. Therefore, there is an opportunity for use of this unused storage space that is available on the client devices to provide additional functionality to client devices and content providers.
Systems, methods, and apparatus for content storage, auction, and management are described. In an implementation, unused storage space that is available on the plurality of client devices is monitored and maintained by a head end such that the head end is “aware” of the amount of available storage space on the client devices. For instance, the storage space may be “set aside” by a provider (e.g., manufacturer, network operator, and so on) of the client devices (e.g., DVRs) such that the head end is aware of the amount of storage space that is set aside. In another instance, the head end is aware of how much storage space is not currently being utilized by each of the client devices, such as by monitoring (e.g., polling) the client devices, receiving a communication from the client devices, and so on.
The head end may then expose this available storage space for purchase to a plurality of potential purchasers. This storage space may be utilized to provide a wide variety of functionality, such as to push video on demand (VOD) content for local storage on the client devices, for local storage of advertisements on the client devices, and so on. For example, the head end may auction the storage space to the plurality of potential purchasers for bidding. Based on the bidding, the head end may determine which of the potential purchasers has “won” the right to content on the plurality of client devices and cause the content to be stored on the client devices. Thus, the content is locally obtainable by the respective client devices.
Local storage of content may provide a variety of additional functionality. For example, the head end may receive unexpected content, such as overtime in a sporting event. Due to the high likelihood that users will wish to view the sporting event, the unexpected content item may be viewed by a vast number of viewers and therefore provide a large potential audience. The head end may offer an opportunity to output one or more of the locally-stored content (e.g., advertisements) in conjunction with the unexpected content, such as by again providing an auction to those potential purchasers which previously stored content on the client devices. Thus, the advertisements may be output to a large potential audience for a payment amount that may accurately reflect the magnitude of the opportunity. Although DVRs have been described, a wide variety of client devices and systems may employ similar functionality without departing from the spirit and scope thereof, such as network enabled computers, wireless phones, and so forth.
The same reference numbers are utilized in instances in the discussion to reference like structures and components.
Overview
Systems, methods, and apparatus for content storage, auction, and management are described. In an implementation, a system is described which facilitates auctioning of local storage space on client devices. For instance, an operator (e.g., a cable provider), having reserved some hard drive space for other business arrangements, might have some capacity left over on each digital video recorder (DVR). The operator may auction the space to the highest bidder for local storage of content. This auctioning may support a variety of business models, such as a “pay for space” on each of the client devices, “percentage of revenue for pay to play”, and so on. For example, content owners may access an online auction via a web browser and enter a bid. Successful bidders may then use the system to push content to the client devices, such as to push advertisements and other content items for local storage on the client. Another auction may also be provided for output of the locally-stored content items, such as advertisements in conjunction with an unexpected content event (e.g., overtime in a sporting event), an opportunity to output locally stored video, and so on.
A classic problem in traditional advertising is due the occurrence of unexpected content items (e.g., extra innings in a baseball game), which are typically not pre-sold by advertising sales departments. However, extra innings in a baseball game may imply a close game and consequently an increased interest level by viewers of the game and a larger audience. Thus, the advertising inventory in this unexpected content item may a corresponding increased value to advertisers. By providing an opportunity to output advertisements in conjunction with the unexpected content item, the auction system may provide additional advertising opportunities that benefit both advertisers and operators.
The auction system may also be configured to provide reporting services such that potential purchasers may make an informed determination of the value of the opportunity that is being offered for purchase. For example, the advertising industry, in general, may desire a move toward a more accountable format, in that the advertising opportunity being purchased may accurately reflect the exposure to potential consumers. Therefore, the auction system may employ a reporting system which describes the number of current viewers of a content item, demographics of the viewers, and so on, and then offer an opportunity, for purchase, to output an advertisement in conjunction with the content item. In the following discussion, exemplary environments and systems will first be discussed which are operable to implement content storage, auction, and management techniques. This discussion will then be followed by exemplary procedures which may be implemented in the described environments and systems.
Exemplary Environment
The client layer 102 may serve a variety of functions. For example, the client layer 102 may include a content maintenance layer 108, which is a sub-layer of the client layer 102 and is executable to maintain and update assets (i.e., content items) on a client device, such as subscriber-selected video assets, push content, and advertising. The client layer 102 may output these assets based on a variety of considerations, such as subscriber input and business rules. The client layer 102 may also be configured to report what assets, if any, are currently stored on a respective client device through execution of an included reporting layer 110. For instance, the reporting layer 110 may be executable to form a communication for transmission to the inventory control layer 104 such that the inventory control 104 may track the amount of available memory storage space.
The inventory control layer 104 may be managed by an operator of a network system, such as a cable provider and so on. Like the client layer 102, the inventory control layer 104 also has a variety of responsibilities. For example, the inventory control layer 104 may expose available memory storage space reported from the client layer 102 to the auction layer 106, may accept assets (i.e., content) from the auction layer 106 for communication to the client layer 102, and so on. In another example, the inventory control layer 104 aggregates asset reports from the client layer 102 through execution of an aggregation layer 112. For instance, the inventory control layer 104 may accept a plurality of reports from a plurality of client layers (and their respective reporting layers) and aggregate these reports for communication to the auction layer 106. The aggregated reports may be utilized to notify potential purchasers of the available storage space and the number of client devices having the available storage space. The aggregation layer 112 may also be executed to supply demographics of the clients, such as user preferences and so on. In a further example, the inventory control layer 104 includes a content management layer 114 that is responsible for managing content storage on client devices. For instance, the content management layer 114 may “age out” pushed assets based on business rules, and so on. For instance, upon the expiration of a business relationship (e.g., a contract) with a particular content provider, the content management layer 114 may cause corresponding content that is stored locally on the clients to be removed.
The auction layer 106 of
The auction layer 106 also provides for the execution of the auctions through an auction bidding layer 118. The auction bidding layer 118, for instance, may provide time-limited auctions, sealed-bid Dutch auctions, and so on. Bidders (i.e., potential purchasers) may log into the auction layer 106, such as by presenting their credentials for authentication as part of the log-in through the web-based user interface 116. If the bidder is authenticated, the bidder may then place bids on available inventory lots, i.e., portion of memory on the client devices. Once the bid is placed, the auction bidding layer 118 may be executed to periodically inform the bidder on the progress of the auction (for timed auctions), on the final disposition of a bid when the auction is completed, and so on.
The auction layer 106 also includes billing layer 120, which is executable to provide billing, reporting, and reconciliation. For example, once a bidder has successfully bid on a part of the disk inventory of a digital video recorder (DVR), the bidder is billed for the disk space that's delivered, i.e., made available to the bidder for local storage of content. The bidder may receive an aggregated usage report from the billing layer 120 to document a return on investment (ROI) for the purchase.
Further, the auction layer 106 includes a content distribution layer 122, which is executable for content (i.e., asset) ingestion and distribution. For example, as previously described, successful bidders are allowed to enter content for the inventory blocks (e.g., portions of disk memory of a DVR) that have been purchased. This inventory may be passed together with metadata that describes business rules (i.e., time windows, reporting rules, and the description of the inventory purchased including target profiles) to the inventory control layer 104 for distribution and management.
The auction layer 108 also includes a management interface layer 124 that allows an operator to set-up auction rules, manage and authenticate bidders, provide and revoke credentials, control access to inventory, and so on. Further discussion of these layers may be found in relation to the following exemplary system.
The content provider 202 includes a plurality of content 212(k), where “k” can be any integer from 1 to “K”. The content 212(k) may include a variety of data, such as television programming, video-on-demand (VOD), one or more results of remote application processing, and so on. The content 212(k) is communicated over a network 214 to a head end 216. The network 214 may be the same as or different from network 206.
Content 212(k) communicated over the network 214 is received by the head end 216 and stored in a storage device 218 as content 220(h), where “h” can be any integer from “1” to “H”. The content 220(h) may be the same as or different from the content 212(k) received from the content provider 202. The content 220(h), for instance, may include additional data for broadcast to the client 204(n). For example, as previously described, the content 220(h) stored in the storage device 218 may include advertisements, video on demand content for local storage on the client device 204(n), and so on. Distribution from the head end 216 to the client device 204(n) may be accommodated in a number of ways, including cable, RF, microwave, digital subscriber line (DSL), and satellite.
The client device 204(n) may be configured in a variety of ways to receive the content 220(h) from over the network 206. As illustrated, the client device 204(n) may be configured as a set-top box 208 that is communicatively coupled to the display device 210. As previously described, the client device 204(n) may also be configured as a wireless phone, a game console, a broadcast-enabled computer, an information appliance, and so on. Although a display device 210 is shown, a variety of other output devices are also contemplated, such as speakers.
The client device 204(n) may also include digital video recorder (DVR) functionality. For instance, the client device 204(n) may include a storage device 222 to record content 220(h) received from the network 206 for output to and rendering by the display device 210. The storage device 222 may be configured in a variety of ways, such as a hard disk drive, a removable computer-readable medium (e.g., a writable digital video disc), and so on. Content 224(m), where “m” can be any number from “1” to “M”, that is stored in the storage device 222 of the client 204(n) may include copies of the content 220(h) that was streamed from the head end 216.
The client device 204(n) includes a navigation module 226 that is executable on the client device 204(n) to control content playback on the client 204(n), such as through the use of one or more “trick modes”. Trick modes may provide non-linear playback of the content 224(m) (i.e., time shift the playback of the content 124(m)) such as pause, rewind, fast forward, slow motion playback, and the like. For example, during a pause, the client device 204(n) may continue to record the content 220(h) in the storage device 222 as content 224(m). The client device 204(n), through execution of the navigation module 226, may then playback the content 224(m) from the storage device 222, starting at the point in time the content 224(m) was paused, while continuing to record the currently-broadcast content 220(h) in the storage device 222 from the head end 216. Thus, the client device 204(n), through use of the storage device 222, may provide DVR functionality.
As previously described, even though the storage device 222 may be utilized to record a large amount of content 224(m), the storage device 222 may still include unused storage space 228. The unused storage space 228 may be available for a variety of reasons. For instance, a manufacturer and/or provider of the client device 204(n) (e.g., a cable television provider) may retain a portion of the storage device 222 as available for the head end 216 to push content 220(h), such as to provide locally stored video-on-demand (VOD), advertisements, and so on as previously described. In another instance, the unused storage space 228 is a portion of the storage device 222 that is not currently being used to store the content 224(m).
To manage the unused storage space 228, the head end 116 includes an inventory control layer 104 which is executable on an inventory server 230 to manage the unused storage space 228 on each of the client devices 204(n). For example, the inventory control layer 104 may be executed to expose the unused storage space 228 as available for purchase to the content provider 102 over the network 106 as previously described in
Upon purchase of the one or more portions, the content 112(k) may be communicated directly to the client device 204(n) for storage in the previously unused storage space 228 of the storage device 222. In another implementation, the content 112(k) is first communicated to the head end 216 for subsequent communication to the client device 204(n) by the inventory control layer 104 as previously described. For example, the inventory control layer 104 may be executed to push the content 220(h) to the client device 104(n) for storing on the storage device 222.
In the illustrated environment 200, the auction layer 106 is executed on an auction server 232. Although illustrated separately, the auction layer 106 and the inventory control layer 104 may also be implemented together on a server, server cluster, and so on. The auction layer 106, when executed, may provide a user interface 116 of
Generally, any of the functions described herein can be implemented using software, firmware, fixed logic circuitry, manual processing, or a combination of these implementations. The terms “layer”, “module,” “functionality,” and “logic” as used herein generally represent software, firmware, or a combination of software and firmware. In the case of a software implementation, the layer, module, functionality, or logic represents program code that performs specified tasks when executed on a processor (e.g., CPU or CPUs). The program code can be stored in one or more computer readable memory devices for execution on a processor. The features of the distribution, storage, and purchasing strategies described below are platform-independent, meaning that the strategies may be implemented on a variety of commercial computing platforms having a variety of processors.
Exemplary Procedures
The following discussion describes distribution, storage, purchase and output techniques that may be implemented utilizing the previously described systems and devices. Aspects of each of the procedures may be implemented in hardware, firmware, or software, or a combination thereof. The procedures are shown as a set of blocks that specify operations performed by one or more devices and are not necessarily limited to the orders shown for performing the operations by the respective blocks.
The available storage space in the storage device is then exposed for purchase to a plurality of potential purchasers (block 304). The exposure of the available storage space may be accomplished in a variety of ways. For example, the auction module 106 of
After the exposure of the storage space (block 304), purchasing information that is obtained from the plurality of purchasers (block 306) is processed. For example, the billing layer 118 of
If the available storage space has been successfully purchased (decision block 308), content from the successful purchaser is communicated to the client for storage on the storage device (block 310). The content in this exemplary procedure 300 may take a variety of forms. For example, the content may be configured as a VOD for local storage on the client device, a game for purchase by a user of the client device, an advertisement, and so on. For instance, the content 220(h) of
Upon receipt of the indication, an offer is made to purchase an opportunity to output an advertisement that is stored on the client (block 404). Like the exposing (block 304 of
Purchasing information received in response to the offer is then processed (block 406). For example, the auction layer 106 of
The auction layer 106 then communicates with the inventory control layer 104 of
The output of the particular advertisement may be performed in a variety of ways. For instance, continuing with the previous example, the selected advertisement may be output in conjunction with the unexpected content item (block 410). Therefore, the selected advertisement may be output to a large potential audience that may wish to view the unexpected content item. During a playoff following a regularly scheduled golf event, for instance, the advertisement may be output while the golfers transition between holes. Because more viewers are likely to tune into the playoff than watch the entire golf event, the advertisement may be output to a larger potential audience. In another example, the unexpected content item (e.g., a live feed of a breaking news event) may replace a rerun of a television program, and thus have a greater potential audience.
The procedures 300, 400 as described, respectively, in relation to
The available storage space is then offered via an auction to a plurality of potential purchasers (block 504). For example, the auction layer may provide an auction web site that describes the availability of the storage space. The auction web site may be provided utilizing a variety of techniques. For example, the auction web site may provide a “sealed-bid” type auction in which only one bid is allowed from each potential purchaser, with the highest sealed-bid “winning” the auction. In another example, a “Dutch” auction may be utilized. The Dutch auction is named a system used for buying and selling flowers in Holland, and is commonly used to sell securities (e.g., treasury bonds). In a Dutch auction, a seller typically seeks bids within a specified price range. After evaluating the range of bid prices received, the seller accepts the lowest price that will allow the seller to dispose of the entire block.
In a further example, a highest-bidder auction may be provided in which bidders are allowed to submit multiple bids during a predetermined period of time, which may be referred to as the “auction period”. Once the auction period has expired (decision block 506), the auction layer of
The auction layer may then communicate with the inventory control layer to indicate the winning bidders. The inventory control layer, upon receipt of the communication, may then obtain content from each winning bidder (block 510). For example, the inventory control layer 104 of
The inventory control layer may then be executed to cause the obtained content items to be stored on the client devices (block 512). For example, the inventory control layer may form a communication for each of a plurality of client devices, the communications including the advertisements. The advertisements may be communicated in a variety of ways, such as streamed from the head end 216 with content 220(h) of
Upon receipt of an unplanned program, an opportunity is offered via an auction to a plurality of potential purchasers to output an advertisement stored on a plurality of client devices (block 604). For example, the head end may email each of a plurality of potential purchasers regarding the occurrence of the unplanned program, the content of the unplanned program, and an estimated number of client devices which will output the unplanned program. The email may reference an auction website, at which, an opportunity to output a previously stored advertisement will be offered via an auction. The potential purchasers may then interact with the auction website to bid on the opportunity as previously described. In an implementation, the bidding is allowed to occur for a predetermined amount of time. For example, the head end may determine when each opportunity to output an advertisement in conjunction with the unexpected content item is to occur. Therefore, the head end may provide a plurality of auctions for each of the opportunities, each having an auction period that is set to enable sufficient time to determine a winner of the auction and cause an advertisement of the winning bidder to be output by the plurality of client devices.
In this implementation, a determination is made as to whether the auction period has expired (decision block 606). If so, the head end (and more particularly the auction layer) collects and processes payment information from the winning bidders, i.e., the purchasers of the opportunity (block 608). The head end then causes the advertisements of the winning bidders to be output by the client (block 610), such as through communication of the auction layer 106 with the inventory control layer 104 of
A module, for example, may be executed to monitor a content item for an occurrence of an unexpected event in the content item (block 702). For example, the unexpected event may occur during the output of the content item (e.g., a close football game in the fourth quarter) and/or before the output of the content item (e.g., an unexpected rise in viewership of a previous episode). When the unexpected event has occurred, an opportunity is offered to a plurality of potential purchasers to output an advertisement by the client devices (block 704). For example, the opportunity may be provided as an auction as previously described.
Payment information may then be collected and processed from the purchaser (block 706). An advertisement from the purchaser is substituted, for output, for an advertisement from a previous purchaser, if any (block 708). In this way, the payment collected for the substituted advertisement may accurately reflect the change in viewership caused by the occurrence of the unexpected event.
Although the invention has been described in language specific to structural features and/or methodological acts, it is to be understood that the invention defined in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claimed invention.
