Patent Application
20080109911
Media players are in common use among a broad base of users. Radio and television have provided entertainment for generations of users. Portable transistor radios of the 1960s began a trend to smaller and more robust personal media players including very small players storing all digital content on both rotating and non-rotating media. Streaming media is available over both wireless and wired networks and may be displayed on cellular telephones and other portable media devices.
Copies of digital media have been a source of problems for digital media copyright holders for some time. The ability to easily reproduce flawless copies makes digital media a particularly attractive target for illegal copying. Digital rights management (DRM) techniques can be used to combat unauthorized copying but can also have some undesired side-effects. Often, consumers feel limited in their ability to move purchased media between their own players, limiting the enjoyment of what they feel they already own. For example, a cassette tape can be played on any cassette player but, in some cases, digital media can only be played on the device originally associated with the purchase. Similarly, a cassette tape can be loaned to a friend to preview, which may spark their purchase of the media. As a result, when DRM schemes limit copy and playback, including sharing with others, even the publisher who imposed the DRM requirement may experience unwanted side effects.
A media player may be adapted to send and receive digital media, such as music, photos, or videos, and enforce a special, limited term license for such digital media shared by another user. In one embodiment, digital media sent by one user to another user may be played a predetermined number of times over a predetermined period of time, for example, three plays or three days, whatever comes first. That is, three days after the media was received or after being played three times, the digital media may no longer be playable by the user. An automated log or journal entry may be used to record the receipt of the media and associated data, allowing the user to recall what media they have received, even if it is not accessible for playback.
a-d are illustrations of a portable media device user interface; and
a-c are other illustrations of a portable media device user interface.
The media device 100 may also include additional storage 108 (removable and/or non-removable) including, but not limited to, magnetic or optical disks or tape or any other memory that can be easily rewritten, may keep data for long periods of time when power is removed, and may allow quick and efficient access to data. Such additional storage is illustrated in
The processing unit 102 may be any processing unit 102 capable of executing computer code to decode media data from a compressed format into a useable form fast enough such that music and video may be played continuously without skips or jumps. When in a portable media device, ii may also be useful if the processor 102 efficiently uses power to increase the life of the power source. The processing unit 102 may also be used to execute code to support a user interface and external communications.
The user interface may include one or more displays 114 for both displaying control information and displaying viewable media. The display 114 may be a color LCD screen that fits inside the device 100. User input(s) 116 may include either manual buttons, soft buttons, or a combination of both. Soft buttons may be used when the display 114 includes a touch screen capability. Manual buttons may include re-definable keys with programmable legends.
A security module 122 may be coupled to the processor. The security module 122 may be used to store cryptographic keys used in digital rights management (DRM). The security module 122 may also have specialized hardware or processors for performing cryptographic calculations, such as stream decryption, without burdening the processor 102. Lastly, the security module 122 may include secure memory for storing record data associated with limited use rights for received media objects. The security module 122 may also include a tamper resistant clock for determining expiration periods on licenses. Management of limited use rights for media objects is discussed in more detail below.
The media device 100 may also contain communications connection(s) 125 that allow the device 100 to communicate with external entities 124, such as network endpoints, other media devices, network access points, or a computer used for synchronization. Communications connection(s) 125 is an example of communication media. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic. RF, infrared and other wireless media. The term computer readable media as used herein includes both storage media and communication media.
The power source may be a battery that may be rechargeable. The power source may also be a standard battery or an input from a power converter.
In operation, a user may connect to external entities 124 through a variety of network types to include local and wide area networks using any number of communication protocols and standards. For example, a media device may connect to a network implementing any of the Ethernet, ARCNet, FDDI, IEEE 1394. Token Ring, or TCP/IP standards. Media devices may connect to each other through a central access point or in an ad hoc fashion. Once connected, the devices may share and transfer data files including media content. A user may receive a media object, including, for example, music or video content, over the communication port 125.
In one embodiment, the media object may be sent over an ad-hoc wireless network from an external device 124. To illustrate, the media object may have been purchased for use on the external device 124 and the user of the external device 124 may be entitled to full and unlimited access to that media object using that device. The user of the external device may wish to share the media object with a user of the media device 100 and may forward the media object to the media device 100. Media content may encompass more than audio or video information. Media content may include electronic books, computer games, podcasts, animations, photographs, or other digital content.
Referring to
Further, individual DRM rules or limited use licenses may be attached to each of the media object's component elements 200. The DRM rule may be any rule or set of rules that limits the use of protected works to allow content owners to determine and control who and how users can view, use, and share digital media objects. For example, a DRM rule may limit the number of times an object may be played within a specific time period. As shown, playable content 203 has license 210, while metadata 202 has license 216, label art 204 has license 212, and the promo cut 206 has license 214. By associating an individual license with each element, different rules may be applied, for example, allowing the promo cut 206 to be played at any time, whereas the playable content 203 may be restricted to a limited use license. Instead, or additionally, the entire media object 200 may be subject to a media object license 218 which may apply to all the elements incorporated by the media object 200. Each element may not be present in every media object 200. For example, a media object may only have playable content 203. In one embodiment, when an element or media object license is not present, rules in the media device 100 may be activated to apply a default license to the received media object 200, or any predetermined element.
In one embodiment, a user may be allowed to browse through the library of another user, given appropriate permission. This so-called shadow-browsing may allow the person browsing to request to download one or more items from that user's library. If the request is granted, the first user may receive a full version, 3-day, 3-play version, or promo cut of the requested item, depending on the license status of the requested item.
When an object 200 is received at another media device 100, the device may determine the presence of content 201, metadata 202, and their associated sub-elements. Each element found may then be examined for license information related to an ability to use the media object 200. For example, a specific media object 200 may include elements of playable content 203, metadata 202, and cover art 204. Only the metadata 202 and cover art 204 may be available for unlimited use. The metadata 202 may include links to a web site for purchase as well as other works by the same artist and related information. By not limiting access to the metadata 202, the user may retrieve information to purchase the content after the license 210 has expired. Further examination may disclose that the content 201 is only available for limited, preview use. For example, the promo cut 206 may be available for rendering and may or may not be subject to further limited license terms. Also, if the media object 200 is received containing no explicit license terms, a default set of limited rights may be applied to any or all elements of the media object 200.
Terms of a limited use license may include the number of times the content may be played or a period of time over which the content may be played. In one embodiment, limited use terms may include unlimited plays for a 24-hour period. In another embodiment, limited use terms may include five plays over an indefinite period of time. When the media object 200 is part of a subscription package, unlimited use may be allowed during the subscription period. Other metrics for limited use may be appropriate when the media is not strictly playable, such as music or video content. For example, an electronic book may restrict the number of pages displayable or a game may restrict the number of levels that may be accessed. Alternatively, a combination of number of plays over a time period may be used. For example, content 201 may be allowed to be played a maximum of three times over a period of three days. To track this, a record of the date and time the media object 200 was received may be recorded and memory allocated for counting the appropriate metric, such as page count or the number of times played. Optionally, media object metadata may also be transferred to the record. Each time the media object 200 is accessed, even for display, the record may be accessed to determine if the time allocation has been exceeded or if the number of plays has been exceeded. If either condition indicates the media object 200 should be expired, a range of steps may be taken to prevent the user from accessing at least the content portion 201 of the media object. For example, upon expiration, the device 100 may delete the media object 200 completely, may alter the appearance of the media object 200 metadata 202 in the user interlace 106, or may not display the metadata on the user interface 106 at all, but instead, store the metadata 202 for later access while deleting the content portion 201. At a later time, the user may access the metadata 202 to re-acquire a license to play the content 201. In one embodiment, the record may be retained and queried to allow the user of the media device 100 to list information about media he or she has received as well as obtain purchase information about specific media objects. The purchase information may allow a user to make a direct purchase of the media object, for example, over a WiFi network accessible from the media device 100.
The methods illustrated in the figures and described below may be implemented on a variety of wired and wireless networks and connections. While the following procedures are described from the standpoint of an external entity 124 connected to a media device 100, the method may also describe any compatible device connecting to either the external entity 124 or the media device 100. In
Some media objects 200 may be unlicensed, for example, a user's photograph or photo album. When no license exists a journal entry may be created, but since no license is involved, a limited use license may not be applicable. However, in one embodiment, a user may be given the opportunity to mark user created objects as being sharable, either completely or in a limited fashion. When marked as limited, the same limited use terms and journaling may be applied as are applicable to licensed objects from media publishers.
At block 301, the media object 200 may be communicated from a first device 100 to an external entity 124 using a variety of file formats and communication methods. For example, the object 200 may be transferred via a wireless network link such as that described by the IEEE 802.11 standard. The object 200 may also be transferred over a wired network implementing any suitable communication method in a compressed or uncompressed digital format and may consist of both content and metadata.
At block 302, a license may be applied to each element of the media content, where the license specifies rights associated with each corresponding element of the media object. Alternatively, one license may be applied to the entire media object. Applying a license to the entire media object 300 or to individual elements may follow a generally known process of digitally encrypting and signing a licensed portion and distributing a key for decrypting to authorized users. In another embodiment, digitally signed media may be used to identify rightful owners without encrypting the actual content. Any device that may participate in the communicating transaction may apply the license to the media object 200.
At block 304, the media object 200 may be received at a media device, such as media device 100 of
At block 306, a record of the receipt of the media object 200 may be created as a durable record of the receipt. The record may be kept as a “journal” of the objects 200 received by the device 100 over the course of its lifetime. The journal entry is more fully explained in relation to
If the license terms have been met, the ‘yes’ branch from block 310 may be taken to block 312, where each of the authorized elements may be made available for playback or use. Additionally, the statistics for tracking use against a limited use license may be initialized, in one embodiment, either a number of plays to be allowed or an expiration date/time based on the receipt date/time and the term of the limited use license. Such statistics may be maintained in the security module 122 to reduce susceptibility to tampering. Each time the media is rendered, that is, requested, queried, displayed, or played, the license terms may be re-evaluated at block 314. The stored number of plays may be checked against a maximum number allowed, the current date/time may be compared against the previously calculated expiration date/time, or both may be checked. Other criteria may also be used, for example, an unlimited use license may be revoked only if evidence of tampering is apparent. Another license may be tied to a subscription, where unlimited plays are allowed during a subscription period. The license for one element may be independent of licenses for other elements of the same media object, that is, a license for a promotional cut 206 may be valid as long as copyright notices are present, where a license for the playable content 302 may only be valid during the limited license period. Licenses may be tied to classes of media objects, in one embodiment, a subscription license may apply to all media objects with metadata that defines the media object 200 as belonging to the subscription, for example, by record label.
When the license is valid for the requested element, the ‘valid’ branch from block 314 may be followed to block 316 and access to the requested element, or the entire media object 200, may be granted. Access may range from simply listing of the media object 200 or its component elements in a user interface 106 to playing the content 203. Other uses of the media object elements may include using the metadata to find artist or purchase information, or to use the label art 204 as a screen wallpaper. Upon access, a number of graphical user interfaces may be presented and managed according to
When the license terms are not met at block 310 or the license is no longer valid at block 314, the respective ‘no’ and ‘expired’ branches may be followed to block 318 where the media object, or individual elements, may be blocked. Blocking may include removing the media object 200, or elements, from a listing of available objects or deleting the media object 200 from the media device 100. When the media object 200 is hidden, so that requests to list available media objects do not include the removed item, it may be retained so that a future purchase or subscription may allow re-presentation of the media object 200 without an additional download process, potentially saving time and inconvenience.
The media identifier 404 may be a unique identifier that corresponds to the media object 200 itself. For example, the media identifier 404 may be a bar-code like number assigned by the publisher that incorporates portions for identifying the publisher, copyright holder, the work itself and any track identifiers. Alternatively, the media identifier 404 may simply be the text of the name of the album/CD and the song, or movie. The media identifier 404 is ideally assigned by an industry association or by the publisher in accordance with an industry standard. When media has limited rights, such as a three play limit, the media identifier can be used to search other journal entries to see if the limited rights for that work are already expired, as explained below.
The sender identifier 406 may be used to identify the party that shared the media object 200. The sender identifier 406 may be a device global unique identifier (GUID), a name selected by a user of a sending device, such as device 126, or a combination of the two. The sender identifier 406 may allow a recipient to identify where a certain media object 200 came from and to give the recipient another method of organizing media on the media device 100, that is, by sender. In the case where media content 200 is played directly from the sending media device and no actual media content is downloaded and stored, i.e. a disk jockey session, these first three parts of the media identifier may be all that is entered in a journal entry 400.
The license reference 408 may be an explicit definition of the terms of a license, for example, unlimited, limited, restricted, none. The variables associated with license terms may relate to one or all of use of playable content 203, preview content, metadata use, or access to cover art. Table 1 illustrates a representative relationship between license types and elements of media content. Forwarding relates to a user's ability to send media content to another device and is discussed more with respect to
License status 410 may be used to log status when a limited term license is to be enforced. The license status 410 data may include the date/time when the media object 100 was received for use in calculating an expiration period for the limited term license, when required. The license status 410 may also maintain a count of the number of times the playable content 203 has been used. In some limited term uses, one or both of an expiration date/time or number of plays may be considered when enforcing the limited use rights. License status 410 may be used for tracking not only the media object license 218 but also for individual element licenses 210, 212, 214, and 216. Lastly, the license status 410 may include an overall valid/invalid flag.
A trigger event may cause the status of the media object license 218 or any individual element licenses 210, 212, 214, 216 to be reevaluated. For example, a request to render the media object 200, that is, to list it in on the display 114 or play the playable content 203, or receiving the object 200 at another device's inbox may cause the license status 210 to be consulted to determine if the license is valid or invalid. If valid, the license terms may be extracted from the license reference 408 of the journal entry 400. The license status 410 may be consulted to determine if any limited license terms have been partially met, for example, two plays of three allowed plays. In this example, if the request is to play the playable content 203, the request may be granted and the count increased by one in the license status 410. The count now being equal to three will cause the license status to change from valid to invalid. An appropriate change to the license status 410 may then be made. Other events, such as power up may cause the license validity to be reevaluated.
Other embodiments may support license changes from invalid to valid, for example, acquisition of a general subscription license that covers the media object may override the media object license 218 and effect a change from invalid to valid. As above, this may be reflected in an update in the license status portion 410 of the journal entry 400. In the same fashion that license validity status for the media object 200 as a whole may be periodically reevaluated.
The journal entry 400 and more specifically the license status 410 may also be used to determine if a newly received media object 200 has already been received on the media device 100 and if the licenses for that media object 200 have been partially or fully used. For example, one way to defeat a 3 day/3 play limited license would be to have each media object 200 re-sent to the media device 100 every third day and thereby renew the license indefinitely. The persistent journal entry 400 may be used to determine if the media object 200 has been on the media device 100 before and the license status 410 may be used to determine what, if any, access is still allowed for that media object 300. If the media object 200 has been on the device for one day and played once, in a 3 day/3 play limited license, access may still be allowed. If, on the other hand, the media object was previously played three times or the three day limit has expired, the media object 200 may be immediately expired and either deleted or saved but not displayed.
The journal entry 400 may also include a read flag 414 that indicates whether or not a synchronization device has read the media object 200. For example, device A may send a media object 200 to device B. Device B may perform a synchronization process with another computing device. Upon synchronization, the computing device may review journal entries 400 on device B to determine if there are any new objects 200 that the computing device has not yet processed. Unprocessed objects at device B may not be associated with journal entries 400 having set read flags 414, and the computing device may store the unread media object's metadata 202 or any other data associated with the media object 200. Further, if the media object 200 is a photo or similarly unlicensed object, the computing device may store the object itself. For example, a previously-unread photo on device B may be stored to the desktop of a computing device. After processing, the read flag 414 of the journal entry 400 associated with the unread media object may be set. Once set, the read flag 414 indicates that an associated media object 200 has been read. During subsequent synchronization processes, the computing device may not reprocess the media object 200 associated with the previously-read journal entry 400, but may, however, process all media objects 200 having journal entries 400 with unset read flags 414. The “read” flag 414 may also control object deletion upon license expiration. For example, an inbox object 200 may be deleted after 3 plays or a 3 day limit when the inbox object's journal entry 400 read flag 414 is set. Thus, the journal entry 400 read flag 414 associated with a media object 200 may indicate to a synchronizing computing device whether or not the media object 200 has been previously stored or processed at the computing device.
The access log 412 may contain a media object 200 history. The access log 412 may include the date/time when the item was received and may also include the date/time of each use of the media object 200, for example, the time(s) when the playable object 203 was played. The access log may be persistent and accessible after the media object 200 itself is expired, allowing a user to recall playback, of for example, a song, by the date and time of the event. The access log 412 may also include data corresponding to changes in license status and the triggering event that caused the license status to change. For example, a license may expire when the time limit, e.g. 3 days, runs out. This event may be recorded in the access log 412. Access of or license changes to the media object 200 or any of its component elements 203, 204, 206, 202 by the device 100 upon which the object resides, any other device 100, or external entity 124 may also be recorded in the access log 412.
With reference to
If the media object 200 is covered by one or more licenses, the “yes” branch from block 504 may be followed to block 508. The license validity may be checked to determine if the license is valid or expired, expired including any condition that renders the media object not usable. If the license is expired, the ‘expired’ branch may be followed to block 510 and the request to send is denied and not acted upon. A error message may be sent to the user indicating the action was not completed and, optionally, a specific license condition referred to.
In one embodiment, the notification may include an offer to the user for purchasing a license or otherwise remedying the expiration condition.
If the license is found valid at block 508, execution may continue by following the ‘valid’ branch from block 508 to block 512. At block 512, the media object 200 may be sent to the requested party. In one embodiment, only those elements that have valid licenses may be forwarded. For example, as referred to in Table 1 above, the metadata 202 and promotional cut 208 may be sent when an exemplary limited license is valid, but only metadata may be sent when a restricted license is valid. While one embodiment may be concerned with a validity of the license for a specific media object 200, another embodiment may look at a device-level license, such as a user license or subscription.
As shown, some license types can restrict the user's ability to forward content. This may be especially true when the content was forwarded from another device and, as such, docs not have full rights. In one embodiment, the act of forwarding content with full rights to another media device may strip the media object license 218 from the media object 200. When received, the media device 100 may assign default rights to the content. Because the media device 100 may not have the cryptographic keys required to grant an unlimited license, a lower level license, such as ‘limited’ or ‘restricted’ may be automatically assigned. In one embodiment, a limited or restricted license may exclude access to the playable content 203 of the media object while allowing access to one or all of the other media object components. In a further embodiment, a limited or restricted license may strip media object components from the media object to which the user does not have access, thereby resulting in storing only those components on the device 200 that the user may access under the license terms. If the media device 100 has or obtains full rights to the media object 200, the media object license 218 may be upgraded. In some applications, however, security requirements may dictate downloading a new copy of the media object 200 with a ‘full rights’ media object license 218.
With reference to
At block 610, the media object 200 may be examined upon receipt to determine the media object's 100 composition. The method may determine the presence of content 201, metadata 202, and their associated sub-elements. As previously described, each element found may then be examined for license information related to an ability to use the media object 200. For example, the promo cut 206 may be available for rendering and may or may not be subject to further limited license terms. For example, a promo cut 206 may not be available during a synchronization process to copy to another computing device. Also, if, upon examination, the media object 200 is received containing no explicit license terms, a default set of limited rights may be applied to any or all elements of the media object 200. In some embodiments, where shared objects are not placed directly into a user's library of media objects 200 but are kept only in an “inbox,” sharing of objects from the inbox may be prohibited. This prevents so-called multiple hop sharing, that is, only media objects with a valid license and in a user's library may be shared. However, in an embodiment where the media object copyright owner determines that an economic argument can be made for the advertising value of multiple hop sharing, certain media objects 200 may be marked as being sharable from the inbox. Such media objects 200 may include podcasts, photographs, or promo cuts with an embedded advertisement.
Further, the received object may be checked to see if the same content 201 has already been received and any corresponding rights previously exhausted. For example, the receiving device 100 may examine the objects that are presently listed in the inbox, or the device 100 may access a local or remote journal file 400 that contains historical information related to media objects 200 that have been received by the device 100. The journal file 400 may be compared to the metadata 202 of the incoming media object 200. In one embodiment, objects 200 may only be received by a device 100 a limited number of times. For example, to prevent periodically re-receiving a previously-received object and thereby circumvent a DRM rule or license term, the object 200 may only be received once. Also, if multiple, identical objects 200 are received at the device, the device may determine which of the objects becomes an “active” object 200 to be stored in the inbox cache 104, 108. For example, the device 100 may determine that the first media object 200 to be rendered out of the multiple identical media objects is to be stored in the cache 104, 108, while the remaining identical media objects 200 are discarded. Also, the received object's metadata 202 may be compared to the journal file 400 to determine the object's validity. For example, if the media identifier 404 of a present inbox object matches the incoming object identifier, then the object 200 may be refused.
Still further, the user may optionally include personal validation conditions for shared media objects received at or sent by the device 100. For example, the user may select an option that only accepts inbox items from specific senders on a trusted list, or from sources to which the user has a current or previous subscription. Also, the user may optionally choose to manually accept or decline each item or object 200 received at the inbox, regardless of the source or a class of sources.
If, at block 620, the incoming object is not valid, at block 625 the object 200 may be refused by the device 100. In one embodiment, refusing the object 200 may result in sending a notification message to either or both of the intended recipient and the object sender. For example, the message sent after refusal may include an offer to purchase the media object 200, renew a subscription, or otherwise gain a full or limited license to access and render the object 200. In a further embodiment, all or a portion of the object 200 may be removed from temporary memory 110. For example, all or a portion of the object 200 content 201 may be removed, while the metadata 202 may be optionally entered into a journal file 400. If, at block 620, the inbox object 200 is valid, the method 600 may proceed to block 630.
At block 630, the method may perform an inbox cleanup operation. In one embodiment, an inbox cleanup may compare the incoming media object 200 with metadata, license, and journal information, and eliminate files from the inbox that have expired or otherwise become inaccessible. In another embodiment, the temporary memory used at block 605 may be freed for subsequent use. Further, the method 600 may periodically perform the inbox cleanup 630 as part of a manual or automatic device 100 management operation. In one embodiment, the device 100 may perform an inbox cleanup 630 after a synchronization process with an external entity 124. The method 600 may also create or modify data related to the journal file 400 that may be accessed to determine previous object 200 expirations, refusals, or failed access attempts. The journal file 400 may also be used to ‘unlock’ or gain access to previously-expired objects that may have been removed from the inbox during the inbox cleanup 630. Also, the inbox cleanup may remove all media objects 200 from the main library that have expired, send a notification of the expiration to the user's inbox, or create or modify a journal file 400 to allow a user to renew the subscription or otherwise re-validate a license to restore access to one or more objects 200.
At block 635, the receiving media device 100 may store the transferred object in an inbox cache 104, 108. The inbox cache 104, 108 may reside in either the system memory 104 or storage 108. The media device 100 may include a variety of data storage areas 104, 108 that contain different data file types. For example, the storage areas 104, 108 may include both objects received at the inbox and objects stored permanently as part of a media device library. In one embodiment, memory 104, 108 allocated for the inbox cache is physically distinct from memory 104, 108 allocated for the media device library. In another embodiment, the memory 104, 108 allocated for the inbox cache is only logically distinct from the media device library memory 104, 108. In a further embodiment, the inbox cache may be a dedicated area of the memory 104, and in a still further embodiment, the inbox cache is a dedicated area of the storage 108.
At block 640, the user may access an inbox object. With reference to
The main interface 705 may include a number of menu categories including an option to access the main media library 715. A user may select items 720 from the main interface 705 by activating the media device controls 725. By selecting the media library option 715, the user interface may display a number of actions or other information 730 that the user may access. In one embodiment, the media library interface 715 may be restricted from accessing objects that are currently included in the inbox cache 104, 108 or listed in the inbox interface 735. By restricting the media library interface 715 from accessing objects stored in the inbox cache 104, 108, expired or otherwise inaccessible objects, as well as promo-cut-only 206 enabled objects, and objects acquiring default, limited licenses upon reception at the inbox 735 may not be included in main library functions. For example, inbox objects may be kept from becoming part of a “shuffle” playback function when a user likely would not desire to hear promo cuts 206 or be forced to skin over expired and inaccessible objects. Also, the user may be restricted to sending or sharing media objects that originate from the user's media library 104, 108, as previously discussed, to prevent unauthorized object access by continuously or periodically sending the object to renew limited access and rendering rights that may be associated with shared objects. In another embodiment, the media library interface 715 includes an inbox sub-section 736 that may allow a user to access and render inbox media objects with or without including object from the media library. For example, as discussed below, inbox object to which the user has a current subscription may optionally be transferred to the media library. In another embodiment, if the clock 123 is completely reset or lost due to, for example, a complete battery drain or replacement, the inbox objects may be permanently expired. Also, the inbox objects accessed from the media library interface 715 may be stored in the inbox cache 104, 108.
Returning to block 640, a user may access the new object saved at block 635 by selecting an inbox interface 735 from a main interface 705. In
The inbox interface 735 may allow the user to manage inbox objects 200 individually or the user may select multiple objects to manage. In one embodiment, the user may be presented with purchase 775, remove 780, and send to journal 785 options. Upon selection of the purchase option 775, the user may be directed to a website where he may buy a license granting more rights to the media file. In another embodiment, selection of the purchase 775 option may automatically update or upgrade license information for the selected object 200. Further, the purchase option 775 may also allow the user to renew a subscription to a media object that has expired or otherwise become inaccessible. Selecting the remove option 780 may allow the user to completely remove one or all inbox objects 200 and all metadata 202 information related to the objects from the device 100. Selecting the send to journal option 785 may allow the user to delay a decision to remove or purchase the received media object 200. For example, the send to journal option may retain information related to the object in the journal file 400. From the journal file 400, the user may later choose the purchase 775 or remove 780 option.
In
The inbox object status 765 may change according to the license or DRM rule associated with the object. For example, the status 765 may change between “active” and “expired” if the object 200 is associated with an active or expired subscription service, respectively. Also, a license or DRM rule associated with a once “active” object 200 may dictate that the user may no longer render the object on the device 100, and the device 100 may change the status 765 to “expired.” The device 100 may assign an “active” or “expired” status 765 by accessing and comparing rules or other information from the security module 122, the object metadata 202, any of the object's licenses 210, 212, 214, 216, 218, or the journal file 400.
Additionally, the user may sort and select any of the inbox files 740 according to any of the metadata, license, or journal elements to prioritize the inbox files in likely significance to the user. In one embodiment, the inbox items may be sorted using a variety of criteria including any of the previously described metadata categories, as well as an object type, an object origin, a time of receipt or sending, a sender name, and an expiration 770. For example, a user may sort and render those objects 200 that are about to expire first. The expiration 770 may indicate any data that relates to the accessibility period in which the user may render the inbox object. For example, the expiration 770 may indicate a number of times the user may play the inbox object and the time the user has remaining to access the inbox object. The amount of time the user has remaining to render the object 200 may be displayed in an exact, real-time count down, or as a rounded-up, approximation of the number days remaining. The expiration status 770 may be determined by accessing and comparing rules or other information from the security module 122, the object metadata 202, any of the object's licenses 210, 212, 214, 216, 218, and the journal file 400.
The expiration 770 may also apply to media library 715 objects that are subject to a subscription service. By accessing information related to the user's subscription account, object metadata 202, object license 210, 212, 214, 216, 218, or journal data 400 on the device 100, the device 100 may sort and play the media library 715 and inbox 735 objects for which the user has full license rights according to an expiration time, and regardless of object origin. For example, a first user may be a member of a subscription service and may be permitted to access a large number of media objects 200 through the service. If a second user sends a media object 200 to the first user that is included in the first user's subscription, the first user may have license rights to the media object 200 under the subscription as if the first user had personally selected the media object 200 sent by the second user. The first user may view the inbox media object and, if desired, may select the item to become part of the main media library. In one embodiment, the first user may transfer an inbox media object 200 that is included in the first user's subscription from the inbox cache to the main media library. The first user's access to an inbox media object 200 that is included in the first user's subscription may be allowed under the first user's subscription terms and whether or not the second user is a member of the same subscription service.
Selecting the media object at block 640 may also give the user access to options that may allow the user to ‘upgrade’ a limited license or otherwise manage individual inbox objects 760. In one embodiment, as at the previously-described inbox interface 735, the user may be presented with purchase 775, remove 780, and send to journal 785 options.
At block 650, the method may determine if the selected inbox file 740 is suitable for rendering. In one embodiment, the method may check to ensure that the limited use licenses 210, 212, 214, 216, 218 are satisfied to allow rendering the media object content as at block 620. As previously discussed, the licenses, or DRM rules, may be associated with the object in a number of ways including, but not limited to, attaching the rule to the media object as it is sent from the first media device 100, or associating a license with the object once it reaches the media device 100 or is stored in the inbox cache 104, 108. If the DRM rule is satisfied to allow further access and rendering by the media device 100, then, at block 660, the user may render the object's content on the media device 100.
If the object 200 is not valid for rendering, at block 670, the method may identify the media object associated with the DRM rule. As illustrated in
Whether the user is viewing active object information 760 (
Table 2 illustrates the media object 200 information that may be visible in the inbox interface 735 or stored in the media library or inbox cache after user input or after a synchronization process.
The use of limited term licenses, including the application of a limited term license to all media objects received in an ad hoc fashion, allows users to share media with other users. This benefits the users by allowing them to share new purchases and old favorites with other users without imposing on the rights of media publishers and copyright holders. Thus, they can share a song or video without putting themselves at the risk of prosecution for copyright violation. The recipient may use the media in accordance with the limited use license to determine whether it would make a good addition to his or her collection. However, because the limited license terms are set by the publisher/copyright holder, they also are protected from rampant unlicensed copying while still allowing songs and videos to ‘sell themselves’ to large word-of-mouth audiences. A limited use license, such as three-days or three-plays may benefit all parties to a sharing transaction: the sender gets to share, the receiver gets to preview from a potentially large base of media, and the publisher can attract purchasers with little or no additional overhead.
Further, media devices that are capable of transferring content controlled by DRM techniques may also provide effective and accessible inbox management. By storing shared objects in an inbox cache that may be separate from the device's main content library, inbox objects subject to short expiration periods or limited accessibility may be excluded from the device's main library functions. Also, expiration and removal of inbox objects may prevent unwanted device resource and memory consumption while improving the user's experience.
Much of the inventive functionality and many of the inventive principles are best implemented with or in software programs or instructions and integrated circuits (ICs) such as application specific ICs. It is expected that one of ordinary skill, notwithstanding possibly significant effort and many design choices motivated by, for example, available time, current technology, and economic considerations, when guided by the concepts and principles disclosed herein will be readily capable of generating such software instructions and programs and ICs with minimal experimentation. Therefore, in the interest of brevity and minimization of any risk of obscuring the principles and concepts in accordance to the present invention, further discussion of such software and ICs, if any, will be limited to the essentials with respect to the principles and concepts of the preferred embodiments.
Although the forgoing text sets forth a detailed description of numerous different embodiments, it should be understood that the scope of the patent is defined by the words of the claims set forth at the end of this patent. The detailed description is to be construed as exemplary only and does not describe every possible embodiment because describing every possible embodiment would be impractical, if not impossible. Numerous alternative embodiments could be implemented, using either current technology or technology developed after the filing date of this patent, which would still fall within the scope of the claims.
Thus, many modifications and variations may be made in the techniques and structures described and illustrated herein without departing from the spirit and scope of the present claims. Accordingly, it should be understood that the methods and apparatus described herein are illustrative only and are not limiting upon the scope of the claims.
