Patent Application
20090193153
With the growing popularity of digital media, some traditional products, such as car stereos and game boxes, now have (or will shortly have) a Universal Serial Bus (USB) port to allow the products to play digital media stored on a device connected to the USB port. A difficulty arises, however, when the digital content is protected by a digital rights management (DRM) mechanism, as the rights to play DRM-protected content are often tied to the portable digital media player that stores the content. To address this problem, Microsoft has introduced a PlaysFromDevice™ specification, which allows certified products to play DRM-protected content from a portable digital media player connected to the product's USB port. This allows the user to listen to DRM-protected content provided by a subscription service, such as Rhapsody™, Yahoo™, and Napster™, either on the portable digital media player storing the content or on a product with PlaysFromDevice™ capability connected to the portable digital media player. When the portable digital media player is used in standalone operation, a user selects stored content for playback using navigation controls and a display device on the portable digital media player, and the portable digital media player plays the selected content via an output device in the player (e.g., for audio content, an audio jack or built-in speaker). However, when the portable digital media player is connected to the product's USB port, controls on the product are used to navigate and select content stored in the portable digital media player, and the selected content is provided to the product and rendered through its output device. For example, with a car stereo with PlaysFromDevice™ capability, a user would select a song for playback using the car stereo's knobs and buttons, and the selected song would play through the car stereo's speakers.
The present invention is defined by the claims, and nothing in this section should be taken as a limitation on those claims.
By way of introduction, the embodiments described below provide a MTP-capable USB device and methods for use therewith. The USB device is provided with circuitry operative to communicate with a host device using a media transfer protocol and receive a command from the host device to play content stored in the memory of the USB device. In one embodiment, the USB device is free of a user input device for providing a command to the circuitry to play content stored in the memory. In another embodiment, the USB device is free of a display device. In yet another embodiment, the USB device comprises a housing comprising a USB Flash drive form factor. Other embodiments are provided, and each of these embodiments can be used alone or in combination with one another.
The embodiments will now be described with reference to the attached drawings.
By way of introduction, the inventors have recognized that when a portable digital media player is connected to a USB port of a PlaysFromDevice™ product, the navigation and output devices of the portable digital media player are not used, as they are superceded by those of the PlaysFromDevice™ product. For example, a PlaysFromDevice™ car stereo's buttons and speakers—not those of the portable digital media player—would be used to select and play a song. Accordingly, a simpler and smaller USB device (e.g., one without a user interface and/or output device), such as a USB Flash drive, can be used to transport digital content to the PlaysFromDevice™ product. Unfortunately, DRM-protected content is transferred using a media transfer protocol (MTP), while standard USB Flash drives use a mass storage class (MSC) format and do not support MTP and DRM. In general, MSC presents a storage device as an ordinary disk drive, while MTP maintains a database index to all files and objects stored on the storage device to allow fast navigation and access to many properties of the digital content stored therein (e.g., album, artist, and genre).
The following embodiments are directed to MTP-capable USB devices that can be used to address the issues noted above. In general, the USB devices of these embodiments communicate with a host device using MTP and receive a command from the host device to play content stored in the USB device. In one embodiment, the USB device is free of a user input device for providing a command to play content stored in the device. Since a user input device on a PlaysFromDevice™ product provides such a command, a user input device on the USB device itself is not needed. Similarly, in another embodiment, the USB device is free of a display device. Because a user does not use a user input device on the USB device to select digital content, a display device used to assist in such navigation is not needed. The USB device also does not contain a speaker or headphone jack to play the content. It should be noted that because a user input device, display device, and speaker are not needed on the USB device (since such functionality can be provided on the PlaysFromDevice™ product), in one embodiment, the USB device can be as simple as a USB Flash (thumb) drive. However, the USB device of these embodiments can take any size, and the claims should not be limited to a USB Flash drive unless that term is explicitly recited therein.
Turning now to the drawings,
The USB connector 108 is a connector that allows communication with another device using USB commands (e.g., MSC and/or MTP). Although the USB connector 108 is show as a protruding plug in
The memory 116 can take any suitable form, such as, but not limited to, non-volatile and/or volatile solid state, magnetic, and optical memories with one-time, few-time, or many-time programmable memory cells. In a presently preferred embodiment, the memory 116 takes the form of Flash memory. The memory 116 is operative to store digital content (sometimes referred to herein as digital media). Digital content can take any suitable form, such as, but not limited to, audio (e.g., a song, spoken word, a podcast, one or a series of sounds, etc.), video (with or without accompanying audio) (e.g., a movie, an episode of a TV show, a news program, etc.), still or moving images (e.g., a photograph, a computer-generated display, etc.), text (with or without graphics) (e.g., an article, a text file, etc.), and a hybrid multi-media presentation of two or more of these forms. For simplicity, in illustrating the following embodiments, the digital content will take the form of digital audio (e.g., songs). The memory 116 can store additional information. For example, in one embodiment, the memory 116 also stores a numeric or alpha-numeric serial number of the USB device 110, which can be used by a digital content subscription service to limit the number of devices per user.
Because the USB device 100 communicates using MTP, the USB device 100 may include a MTP database, which stores metadata associated with digital content stored in the memory 116. Metadata refers to information about digital content. Examples of metadata can include, but are not limited to, information that allows a user to make a selection of the digital content for playback (e.g., song name, album name, artist name, etc.), information that allows a host device to know how to decode and play the digital content (e.g., bit rate, encode method (e.g., MP3 or WMA), order of songs on an album to properly sequence playback of the songs, etc.), and associated information about the digital content (e.g., album art, duration of a song/album, etc.). Metadata can be stored in the file of the digital content itself (e.g., in a header block of the file) or can be stored in a separate location (e.g., a jpeg image of album art can be stored separately from the digital content file). Although some forms of metadata can be the same as information from a file system (e.g., the title of a song can be the same as the actual file name), in general, metadata is usually information other than what is typically gleaned from file system information (e.g., file name and file size).
The circuitry 112 is used to perform various functions as described below. As used herein, “circuitry” can include one or more components and be a pure hardware implementation and/or a combined hardware/software (or firmware) implementation. Accordingly, “circuitry” can take the form of one or more of a microprocessor or processor and a computer-readable medium that stores computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, an application specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller, for example. In a presently preferred embodiment, the circuitry 112 includes an ASIC, such as an Orpheus 3 ASIC. The Orpheus 3 may contain the necessary CPU and internal RAM (e.g., about 300K) to run a MTP stack. Alternatively, other ASICs or components may be used.
It should be noted that the USB device 100 in this embodiment does not have a user input device for selecting content stored in the memory 116 of the device 100, nor does it have a display device to facilitate such selection. The USB device 100 in this embodiment also does not have an output device (e.g., a speaker or a headphone jack) for playing back digital content stored in the memory 116 of the USB device 100. Accordingly, the USB device 100 is merely used to transport digital content to a host device for playback.
As shown in
In operation, after the user connects the USB device 100 to the host device 140 (act 201, see
In general, digital content protected by DRM is typically encrypted and requires a license, e.g., one provided in accordance with Janus™ DRM. A license is the right or permission to use the content. Without a valid license, the associated content cannot be played. When the digital media files are stored in the USB device 100 in MTP mode, the circuitry 112, using an MTP stack, stores the digital content in one file and the associated license in another file in the memory 116 according to MTP protocols. MTP considers objects to be entities with properties, and operations can be performed on the objects. Mass storage class (“MSC”), on the other hand, presents a storage volume, such as a disk drive. MSC does not allow correlation between one object to another. MSC is a protocol that provides a mechanism to read out data or data sectors on a drive.
In a one-wire implementation, based on the command from the host device 140, the circuitry 112 sends both the encrypted content and a license for the encrypted content to the host device 140 (act 213), and the host device 140 decrypts the encrypted content for playback and license validation (act 217). The host device 140 may also decode or decompress the content and render analog signals for audio or video output. Alternatively, if the content is not encrypted, the host device 140 merely decodes or decompresses the content (and validate the license). In a two-wire implementation, based on the command from the host device 140, the circuitry 112 decrypts the encrypted content, validates the license, and sends the decrypted content to the host device 140 for playback (acts 221, 225). The battery-powered RTC 120 can be used to provide time to the circuitry 112 to validate the license, if time-based. (A serial number stored in the memory 116 can also be used in the license validation process.) The circuitry 112 may also decode or decompress the content. Alternatively, if the content is not encrypted, the USB device 100 can merely decode or decompress the content, validate the license, and send the resulting content to the host device 140 for playback. During the playback, controls on the host device 140 can be used to control operation of the playback (e.g., fast forwarding, rewinding, or pausing content) (act 229).
There are several alternatives that can be used with these embodiments. For example, instead of a host device being a product such as a car stereo of game box, the host device can be a digital media player (a “host player”). This type of host would be a simple, portable device that includes “USB OTG (on the go)” support for a thumb drive, in addition to a USB connection for a host computer. The host player would pass thru the control to the MTP storage module when connected to another computer. When operating in standalone mode, the host player initiates a secure session with the USB device and retrieves content in a manner similar to the car stereo system host. In one embodiment, no Flash storage resides on the host player, and only the decoder, user interface, keyboard, and display firmware may be needed. The host player can optionally boot its device firmware from the USB device, eliminating NAND storage from the host player. The host player can include a rechargeable battery, so it can function on its own and power the MTP USB device.
It is intended that the foregoing detailed description be understood as an illustration of selected forms that the invention can take and not as a definition of the invention. It is only the following claims, including all equivalents, that are intended to define the scope of this invention. Finally, it should be noted that any aspect of any of the preferred embodiments described herein can be used alone or in combination with one another.
