CROSS-REFERENCE TO RELATED APPLICATIONSThis application claims the benefit of priority under 35 U.S.C. §119(e) of co-pending U.S. Provisional Patent Application No. 61/381,014, filed Sep. 8, 2010, entitled “Movie Bites.” The disclosure of the above-referenced application is incorporated herein by reference.
BACKGROUND1. Field of the Invention
The present invention relates to electronic media data, and more specifically, to consuming media data in bites.
2. Background
The distribution of electronic media data (e.g., music, videos, movies, and television shows) may be accomplished using various methodologies. For example, entire media data files may be transferred from a media data server to a client electronic device. Alternatively, a media data stream may be established between the media data server and the client electronic device.
SUMMARYImplementations of the present invention provide for consuming media data in bites. In one implementation, a method of accessing media data in bites is disclosed. The method includes: receiving a request from a client to access a media item, and determining an address of the requested media item, wherein the address indicates a location where the media item is stored; determining an identification number of a piece of the media item selected by the client; updating the address of the media item by combining the address with the identification number of the piece of the media item selected by the client; valuating the piece of the media item selected by the client, and sending a valuated price to the client; and providing access to the requested media item using the updated address of the media item when a payment for the valuated price is received from the client.
In another implementation, a media access controller is disclosed. The controller includes: a media access map to receive a media access request for a media item from a client device, and to output an address for the requested media item; a processor to receive the address of the media item and generate a media access menu which is presented to the client device to enable the client device to select a piece of the media item to access; a combiner to update the address of the media item by combining the address with a selection of the piece of the media item from the client device; a valuator to valuate the piece of the media item selected by the client, and to send a valuated price to the client device; and an access interface to provide access to the requested piece of the media item using the updated address of the media item when a payment for the valuated price is received from the client device.
In another implementation, a non-transitory tangible storage medium storing a computer program for accessing media data in bites is disclosed. The computer program comprises executable instructions that cause a computer to: receive a request from a client to access a media item, and determining an address of the requested media item, wherein the address indicates a location where the media item is stored; determine an identification number of a piece of the media item selected by the client; update the address of the media item by combining the address with the identification number of the piece of the media item selected by the client; valuate the piece of the media item selected by the client, and sending a valuated price to the client; and provide access to the requested media item using the updated address of the media item when a payment for the valuated price is received from the client.
Other features and advantages of the present invention will become more readily apparent to those of ordinary skill in the art after reviewing the following detailed description and accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGSThe details of the present invention, both as to its structure and operation, may be gleaned in part by study of the accompanying drawings, in which:
FIG. 1 is a flowchart illustrating a technique for consuming media data in bites using a media access controller in accordance with one implementation of the present invention;
FIG. 2 is a functional flow diagram illustrating an example process for consuming media data in bites in accordance with one implementation of the present invention;
FIG. 3 is a functional block diagram of a media access controller in accordance with one implementation of the present invention;
FIG. 4A illustrates a representation of a computer system and a user; and
FIG. 4B is a functional block diagram illustrating the computer system hosting the media access control in accordance with one implementation of the present invention.
DETAILED DESCRIPTIONCertain implementations as disclosed herein provide for consuming media data in bites using a media access controller. In reading this description it will become apparent how to implement the invention in various implementations and applications. Although various implementations of the present invention will be described herein, it is understood that these implementations are presented by way of example only, and not limitation. As such, this detailed description of various implementations should not be construed to limit the scope or breadth of the present invention.
When an item of media is available for access, a media access controller can be referenced for media access in bites. In one implementation, a server stores at least one media item as a whole and in pieces or bites. For example, the pieces can be stored separately from the whole such that the media item would be stored twice. In another example, the server stores a table of indices or pointers into the media item to define pieces of the media item. A user can access, view and listen to media items available from the server through a compatible client application on a client device (e.g., PC, game console, or other network-enabled device). The server defines the choices to present to the user. Alternatively, the client device may define the choices or may select from among the possible choices provided to the server to present a subset to the user. In this alternate implementation, the client device presents the option to buy access to the media item as a whole or to one or more pieces of the media item. The user can then choose whether to pay to access the media item in pieces or all at once. If the user buys access to pieces, the user can continue to buy access to the remaining pieces one at a time, in groups, or to the remaining pieces.
Similarly, the client device can present different rights options for the pieces or the media item as a whole. For example, the user can choose to keep the pieces unlocked and accessible indefinitely, or only for a limited period. The client device can also present different pricing depending on purchase activity. For example, if the media item as a whole costs $20 and is divided into 15 pieces each costing $2 (for a total cost of $30 if all pieces are purchased individually), when a user has paid $20 for the pieces obtained so far, the client can offer the remaining pieces free of charge or discounted. In another example, if a user buys access to a first media item as a whole, a piece of another media item may be offered at a discount or for free. In another example, pieces of a media item can be offered at a discount or for free to users participating in a subscription service or loyalty program.
In one implementation, the client device plays multiple pieces of a media item seamlessly transitioning between the pieces. In another implementation, the client device combines the pieces together to form larger pieces or a single piece (e.g., after all the pieces have been purchased). Similarly, software can be provided that allows a client device to combine pieces from multiple items of media to create compilations.
In another implementation, a user can select an option to pay for the portion of content accessed as in a ‘pay-as-you-go’scheme. In one example, a media item is divided into pieces and the pieces are delivered to the client device as needed. Initially, the first piece is delivered and the client device plays and/or displays the first piece of the media item. When a certain threshold is reached, the next piece is delivered and the user can continue to seamlessly view the media item. If the user stops playback, no further pieces are delivered. The user is charged only for the pieces actually delivered or played (e.g., beyond a threshold). The client device can notify the user in various ways of a new piece (and a new charge associated with the new piece) before it starts. For example, the client device can issue and display a pop-up window, icon, or message, or present a dialog box or other confirmation to proceed. In this example, a default setting would be to proceed and charge, with alternative settings including stopping the playback without authorization or charging based on user preference settings. To encourage the completion of the purchase of the pieces, the user could be offered a discount to purchase access to the rest of the media item. Alternatively, the offered discount could be a discount which can be applied against a different item of media. In another example, the entire media item is delivered initially (though playback can begin before completion) but the playback progress through the media item is tracked. The user is charged for the portion played or the entire charge is paid up front but a refund (or “return”) is applied for the unused portion (which would also be locked to prevent further playback without payment). In a subscription model, a subscriber may be allowed a certain number of “returns” of purchased or rented content to receive a refund for unused portions.
The content server and storefront server may be the same system or separate systems. Similarly, the servers can be operated by the same or different companies. Multiple storefront services could access the same content server/service, or one storefront could access multiple content servers/services (or a many-to-many relationship could be used). The content service and storefront service can track the purchasing activity and patterns of consumers, individually and in the aggregate. For example example, a content service tracks which pieces have been accessed or purchased for an account and can provide missing pieces (e.g., the next unviewed piece) to a different device accessing the same account. The client device can also track the local usage patterns. For example, a service can track the conversion pattern (e.g., converting a sale of a segment to a sale of the entire media item) for various criteria, such as consumer demographic, time, price, genre, consumer history, etc. Based on that analysis, a user can be provided with recommendations or promotions that are customized to the user or that the service provider desires to push.
There are advantages to offering and delivering a media item, such as a movie, in pieces rather than as whole. Transferring and storing pieces are easier. For example, transferring and storing a 20 MB or 200 MB piece of a 2 GB movie across a network requires less bandwidth and less storage capacity than transferring and storing the entire 2 GB in one transaction. Sending the media pieces over time also spreads the distribution load over time and provides the pieces closer in time to when the pieces are actually needed. Further, a piece of media item can be offered at a lower price and so may be more attractive to purchase, such as in impulse buying. The initial piece can then serve as a sample or introduction to buying the whole. The initial piece could also be offered for free or included as a promotional with another product (e.g., pre-loaded on a media player). In another example, a user may only want to access part of a movie, such as when the user has already seen half of a movie and only wants to pay to see the remaining half.
FIG. 1 is aflowchart100 illustrating a technique for consuming media data in bites using a media access controller in accordance with one implementation of the present invention. In the illustrated implementation ofFIG. 1, when media access request is detected, atbox110, an address of the requested media item is determined, atbox120. Examples of media for which access requests are received include videos, images, music, television shows, texts (e.g., books or magazines), etc. In one implementation, the determined address refers to an address or pointer to the location where the whole media item stored. In another implementation, the determined address refers to an address or pointer to the location where the first piece of the media item is stored.
A determination is then made, atbox130, as to whether the request for media access is to access the media item in pieces or bites. When it is determined, atbox130, that the request is to access the media item in pieces or bites, the media address is updated, atbox140, by combining the current media address with a media bite number. For example, if the media address for media item123456 is determined to be ‘addr123456’, and the user has selected media bite78, then the updated media address for the media bite can be ‘addr123456078’. Since three digits have been allotted for the bite number in this example, up to 1000 bites or pieces of media123456 can be addressed. In a further example, if the user chooses not to access the media item in pieces but as a whole, then the updated media address can be ‘addr123456000’ which indicates that the bite number for this case is ‘000’. Although the above examples show the combining of the current media address with a media bite number only as appending the media bite number to the end of the current media address, other ways of combining the two numbers are contemplated. For example, in one implementation, the media bite number can be appended at the front of the current media address. In another implementation, each of the two numbers is generated from a function and the combination is generated as a convolution of the two functions.
In some implementations, accessing media items in bites include accessing the media items in time slices or chunks rather than in physical pieces. For example, if a user purchases a 30 minute bite of a movie, the user can use the 30 minute bite all at once to view 30 minutes worth of the movie, or view a 10 minute slice of one movie and if not satisfied, the user can then use the next 10 minute slice for a different movie. This allows the user to sample various media titles. Similarly, in another implementation, a user can purchase slices or time increments that are independent of particular content, which can then be used to access part of a media item selected at a later time. For example, a user could purchase a pack of six 10-minute slices and then use them for later selections. In one such implementation, the purchased slices form a pool or wallet that can be used while watching content to continue past the end of a slice (e.g., after watching 10 minutes of content the player can confirm with the user to continue watching the content and indicate the remaining slices in the pool, or offer the purchase of additional slices or the purchase of the remainder of the content). The granularity of the slices can also vary, such as selling 10 minute or 5 minute slices or selling a pool of individual minutes (similar to a pay as you go model, such as with minutes for a mobile phone). Other implementations may use additional or different bases for the slices or increments, such as download or streaming data, scenes, or chapters (e.g., DVD chapters). In a further implementation, once the user decides on a movie (e.g., a full-length version) to purchase, the time slice or the movie bite is credited towards the purchase of the full-length version of the movie. In one implementation, the user can purchase the media bites at any time and in any order. In another implementation, the user can only purchase the bites in a linear, consecutive sequence.
In another variation, each media bite is marked with a unique identifier tied to a user account or client player so that only bites with that identifier can be played on that player, which can be enforced by a digital rights management (DRM) system. This would prevent multiple users from pooling and combining individual, different media bites to make a complete full-length version of the media.
In yet another variation, users can combine media bites with friends. For example, a user can present a media bite to a friend or another user as a gift. In another example, sharing bites could be a good way to do viral marketing that uses pre-existing social networks to produce increases in brand awareness or to achieve other marketing objective, such as product sales, through self replicating viral processes. In all of the implementations and examples described above, it should be noted that media other than video can be used. For example, media can be audio, text, games, and possibly with different bases for slices or bites, such as pages, words, levels, etc.
Once the selection is made by the user, the requested media item is valuated, atbox150. As discussed above, there are several different options for accessing a media item and thus provide several different ways the requested media item can be valuated depending on the purchase activity. For example, a user can download a media item in pieces that are each two chapters long (e.g., 10% of the movie length) at a price of $2.00 each. There is also an option to buy the whole media item for a second price. The second price may adjust depending on how much the user has already paid. In another example, if the media item as a whole costs $20 and is divided into 15 pieces each costing $2 (total cost of $30 if all purchased individually), when a user has paid $20 for the pieces obtained so far, the client can offer the remaining pieces free of charge (or discounted).
In another example, if a user buys access to a first media item as a whole, a piece of another media item may be offered at a discount or for free. In another example, pieces of a media item can be offered at a discount or for free to users participating in a subscription service or loyalty program. In another example, the user is charged only for the pieces actually delivered or played (e.g., beyond a threshold). The client device can notify the user in various ways of a new piece (and a new charge associated with the new piece) before it starts. For example, the client device can issue and display a pop-up window, icon, or message, or present a dialog box or other confirmation to proceed (e.g., defaulting to proceed and charge, to stop playback without authorization, or to charge based on user preference settings). To encourage the completion of the purchase of the piece, the user could be offered a discount to purchase access to the rest of the media item. Alternatively, the offered discount could be a discount which can be applied against a different item of media.
In yet another example, the entire media item is delivered initially (though playback can begin before completion) but the playback progress through the media item is tracked. The user is charged for the portion played or the entire charge is paid up front but a refund (or “return”) is applied for the unused portion (which would also be locked to prevent further playback without payment). In a subscription model, a subscriber may be allowed a certain number of “returns” of purchased or rented content to receive a refund for unused portions.
Once the valuation is done and the price is set for the requested media item, a determination is made, atbox160, whether the payment has been received. Access to the requested media item is provided, atbox170, once the payment has been received.
FIG. 2 is a functional flow diagram200 illustrating an example process for consuming media data in bites in accordance with one implementation of the present invention. In the example implementation ofFIG. 2, a request210 to access media for Media123456 is received from client X. This request210 is submitted to a media access map220 for client X. This access map220 provides addresses corresponding to all media for which client X has submitted requests for access. In this implementation, the media access map220 indicates that Media123456 is stored in address ‘addr123456000’. The media access map220 also includes a reference pointer to a media access menu230 for Media123456. The media access menu230 provides a series of inquiries to the user to determine whether the request to access Media123456 is to access it in pieces or as a whole. Further, the media access menu230 determines which piece(s) of the media item to access by providing overviews of the pieces to the user. The overviews can be presented to the user in thumbnails, snippets, or other method for presenting short summaries of the pieces to aid the user in selecting piece(s) of the media item. Since three digits have been allotted for the bite number in this example, Media123456 can be divided into up to 1000 bites or pieces. Again, as discussed above, once the selection for piece(s) to access is made and the payment is received, the media item240 is made available for access.
FIG. 3 is a functional block diagram of amedia access controller300 in accordance with one implementation of the present invention. In one implementation, themedia access controller300 is implemented in hardware configured within a server (not shown). In another implementation, themedia access controller300 is implemented as a stand-alone hardware device configured to reside remotely from the server. In the illustrated implementation ofFIG. 3, themedia access controller300 includes a media access map310, acombiner320, aprocessor330, avaluator340, and anaccess interface350. Themedia access controller300 also interacts with aclient device390.
In the illustrated implementation ofFIG. 3, the media access map310 receives a media access request from theclient device390. As described above, the media access map220 provides addresses corresponding to all media for which the user using theclient device390 has submitted requests for access. The media access map220 also includes a reference pointer to a media access menu230. Thus, in response to the media access request, theprocessor330 within themedia access controller300 sends a media access menu230 to theclient device390, which provides a series of inquiries to theclient device390 to determine whether the request to access media is to access it in pieces or as a whole. Further, the media access menu230 determines which piece(s) of the media item to access by providing overviews of the pieces to theclient device390. The overviews can be presented to theclient device390 in thumbnails, snippets, or other method for presenting short summaries of the pieces to aid the user in selecting piece(s) of the media item.
Once the user makes the selection to access the requested media item, the selection is received from theclient device390, and the media address is determined by thecombiner320. For example, if the user selects to access the media item as a whole, theclient device390 sends a bite selection of ‘000’. Otherwise, if the user selects to access the media item in pieces/bites, the selected bite number is sent. For example, if the user selects bite78, a bite selection of ‘078’ is received by thecombiner320. Thus, as described above, thecombiner320 appends the bite selection to the media address generated by the media access map310 to generate a bite address. This address is then passed onto theaccess interface350.
Once the media item selection is made by the user, the requested media item is valuated by thevaluator340 and the price for the media item is sent to theclient device390. Thevaluator340 also sends the price to theaccess interface350 so that when the payment is received from theclient device390, theaccess interface350 compares the payment to the price to determine if a correct payment is received. If it is determined that the correct payment has been received, theaccess interface350 provides access to the media item to theclient device390 using the bite address received from thecombiner320. In another implementation, theaccess interface350 further includes a tracking unit configured to deliver the entire media item to the client device, track a playback progress through the media item, and charge only for the pieces of the media item which have been played.
FIG. 4A illustrates a representation of acomputer system400 and auser402. Theuser402 can use thecomputer system400 to implement media access control. Thecomputer system400 stores and executesmedia access control490.
FIG. 4B is a functional block diagram illustrating thecomputer system400 hosting themedia access control490 in accordance with one implementation of the present invention. Thecontroller410 is a programmable processor and controls the operation of thecomputer system400 and its components. Thecontroller410 loads instructions from thememory420 or an embedded controller memory (not shown) and executes these instructions to control the system. In its execution, thecontroller410 provides themedia access control490 as a software system. Alternatively, this service can be implemented as separate components in thecontroller410 or thecomputer system400.
Memory420 stores data temporarily for use by the other components of thecomputer system400. In one implementation,memory420 is implemented as RAM. In another implementation,memory420 also includes long-term or permanent memory, such as flash memory and/or ROM.
Storage430 stores data temporarily or long term for use by other components of thecomputer system400, such as for storing data used by themedia access control490. In one implementation,storage430 is a hard disk drive.
Themedia device440 receives removable media and reads and/or writes data to the inserted media. In one implementation, themedia device440 is an optical disc drive.
Theuser interface450 includes components for accepting user input from the user of thecomputer system400 and presenting information to the user. In one implementation, theuser interface450 includes a keyboard, a mouse, audio speakers, and a display. Thecontroller410 uses input from the user to adjust the operation of thecomputer system400.
The I/O interface460 includes one or more I/O ports to connect to corresponding I/O devices, such as external storage or supplemental devices (e.g., a printer or a PDA). In one implementation, the ports of the I/O interface460 include ports such as: USB ports, PCMCIA ports, serial ports, and/or parallel ports. In another implementation, the I/O interface460 includes a wireless interface for communication with external devices wirelessly.
Thenetwork interface470 includes a wired and/or wireless network connection, such as an RJ-45 or “Wi-Fi” interface (including, but not limited to 802.11) supporting an Ethernet connection.
A system communication path480 (e.g., a system communication bus) provides for transfers of data and control information between themedia device440,user interface450, I/O interface460,network interface470,storage430,memory420, andcontroller410.
Thecomputer system400 includes additional hardware and software typical of computer systems (e.g., power, cooling, operating system), though these components are not specifically shown inFIG. 4B for simplicity. In other implementations, different configurations of the computer system can be used (e.g., different bus or storage configurations or a multi-processor configuration).
Various illustrative implementations of the present invention have been described. However, one of ordinary skill in the art will see that additional implementations are also possible and within the scope of the present invention. For example, the media item is created to be purchased and distributed in small pieces without a predetermined end (serial network publication). Similarly, different pricing or promotional options or rights management options can be provided. In another example, the techniques can be applied to media items paid for in a rental context (e.g., access is granted only for a limited period of time). Accordingly, the present invention is not limited to only those implementations described above. It is further understood that the scope of the present invention fully encompasses other implementations that may become obvious to those skilled in the art and that the scope of the present invention is accordingly limited by nothing other than the appended claims.