Removable storage content transfer

A system and method for removable storage content transfer. A removable storage medium is passed between a terminal and a device, and a device file stored on the removable storage medium is used to communicate media content and other information between the terminal and the device. The device file may include “session information,” such as information that can be used to represent a network or direct connect session between the terminal and the device file. The session information may include, for example, media content and header information. The device file may allow the terminal to treat the removable storage medium as a locally connected device in some situations. For example, the terminal may create a device stack using device parameters stored on the removable storage medium, and use the device stack to communicate with the device via the removable storage medium.

CROSS-REFERENCE TO RELATED APPLICATIONS

BACKGROUND

Many consumer electronic devices, such as cameras, personal music players, and the like, store files or other content capable of being played back. Increasingly, a personal computer is being used as primary storage for such content. Electronic devices are therefore being designed to interface with personal computers to exchange content. For example, a digital camera may transfer photograph files to a personal computer hard drive. As another example, a personal music player may receive music files from a personal computer.

Storage cards, such as, for example, a Compact Flash (CF) memory card, Secure Digital (SD) memory card, a Memory Stick, or the like, may be used to transfer content between an electronic device and a personal computer. Such storage cards may include, for example, a removable memory device including flash memory. A device may write to a storage card, and the storage card may then be removed from the device and inserted into a personal computer, which may retrieve information from the storage card. Similarly, a personal computer may write to a storage card, and the storage card may then be removed from the personal computer and inserted into the device, which may retrieve information from the storage card. For example, a storage card may be used to transfer photographs from a camera to a personal computer, or to transfer music files from a personal computer to a personal music player.

In some cases, it may be advantageous for a personal computer to process the content before or after a transfer. For example, a music file may be stored in the personal computer as a relatively large high-fidelity file. Prior to transferring the music file to a personal music file for playback, it may be advantageous to transcode the music file into a smaller low-fidelity file. As another example, metadata may be added to photographs received from a camera.

In many cases, content, such as, for example, copyrighted media content, may include protection features, such as by implementing Digital Rights Management (DRM) features. However, multiple technical mechanisms for content protection exist, and various devices may handle content protection mechanisms differently. Furthermore, DRM may specify restrictions on a particular content, a particular device, or both. For example, a subscription DRM service might allow a user unlimited playback of all content on a particular personal music player, such as allowing unlimited playback of all music for one month. As another example, a per-use DRM service might allow a user to play a particular content a particular number of times, such as allowing a user to play a movie once, or allowing a user to play a song three times. The multiplicity of technical mechanisms, the different types of restrictions, and the different methods of handling DRM used by different devices may each complicate the transfer or playback of DRM content.

SUMMARY

In various embodiments, a system and method for removable storage content transfer are provided. A removable storage medium is passed between a terminal and a device, and a device file stored on the removable storage medium is used to communicate media content and other information between the terminal and the device. The device file may include “session information,” such as information that can be used to represent a network session between the terminal and the device file. The session information may include, for example, media content and header information along with any other communication steam that may otherwise occur if two or more devices were directly connected via wired or wireless communication protocol. The device file may allow the terminal to treat the removable storage medium as a locally connected device in some situations. For example, the terminal may create a device stack based upon the device file using device parameters stored on the removable storage medium, and use the device stack to communicate with the device via the removable storage medium.

A computer-readable medium may store instructions executable to cause a computer to perform a method. The method may include obtaining at least one device parameter from a removable storage medium, the at least one device parameter specifying at least one property of an external device. The method may further include creating a device stack based on the at least one device parameter and generating session information based on the device stack. The method may also include transmitting the session information to be stored in a device file on the removable storage medium.

A computer-readable medium may store a data structure, the data structure including a first field. The first field may contain data indicative of a device file, the device file configured to contain session information, the session information representing a session between a terminal and an external device.

A computer-readable medium may store instructions, the instructions being executable to cause a device to perform a method. The method may include obtaining first session information from a device file on a removable storage medium, the first session information being generated by a terminal. The method may further include transmitting second session information to be stored in the device file on the removable storage medium.

DETAILED DESCRIPTION

In one implementation, the invention relates to a system and method for removable storage content transfer.

FIG. 1illustrates an example of a suitable computing system environment100on which the system for removable storage content transfer may be implemented. The computing system environment100is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing environment100be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment100.

With reference toFIG. 1, the exemplary system100for implementing the invention includes a general purpose-computing device in the form of a computer110including a processing unit120, a system memory130, and a system bus121that couples various system components including the system memory to the processing unit120.

The computer110in the present invention will operate in a networked environment using logical connections to one or more remote computers, such as a remote computer180. The remote computer180may be a personal computer, and typically includes many or all of the elements described above relative to the computer110, although only a memory storage device181has been illustrated inFIG. 1. The logical connections depicted inFIG. 1include a local area network (LAN)171and a wide area network (WAN)173, but may also include other networks.

Although many other internal components of the computer110are not shown, those of ordinary skill in the art will appreciate that such components and the interconnection are well known. Accordingly, additional details concerning the internal construction of the computer110need not be disclosed in connection with the present invention.

FIG. 2is a block diagram illustrating an overview of a system in accordance with an embodiment of the present invention. As shown inFIG. 2, a device200, such as a consumer electronic device, may receive content from or transfer content to a terminal202, such as a personal computer. Each of the device200and the terminal202may be equipped with one or more storage readers and/or writers. The device200may be, for example, an automotive built-in media system, a portable digital stereo system, a home entertainment system with built-in storage, a camera, a portable gaming device, a mobile telephone, or any other electronic system. In some implementations, a plurality of devices200may receive content from or transfer content to the terminal202.

The device200and the terminal202both implement a protocol that allows for configuration of the device200and the exchange of information between the device200and the terminal202when a network connection204is established between the device and the PC. For example, both the device200and the terminal202may have Universal Serial Bus (USB) connectors203,204so that the device200can be connected to the terminal202via a direct USB cable206or some combination of USB cables and USB hubs. In some implementations, Media Transfer Protocol (MTP) is used as the configuration and transfer protocol, and both the device200and the terminal202may implement MTP allow for configuration of the device200and the transfer of media objects between the device200and the terminal202. When the device200and the terminal202are connected via the USB cable206, MTP information will be carried over the USB cable206such that configuration and transfer operations can be performed. Those skilled in the art will appreciate that other configuration and transfer protocols could be used, and that various transport protocols could be used. For example, MTP or another configuration and transfer protocol could be used in conjunction with Transmission Control Protocol/Internet Protocol (TCP/IP). As another example, Picture Transfer Protocol (PTP) could be carried over the USB cable206or used in conjunction with another transport protocol.

When a network connection is established between the device200and the terminal202, via the USB cable206or some other connection, discrete packets of information may be sent from the device200to the terminal202, or from the terminal202to the device200. The time it takes to perform such a transfer may depend on the latency of the network connection, and how reliable such transmission is may depend on the reliability of the network carrying the connection. Both the configuration and transfer protocol and the transport protocol may include mechanisms to make the best use of the network connection (reduce the latency) while reducing transmission errors (improving the reliability).

The communication between the device200and the terminal202over the USB cable206or other network connection may include one or more sessions. Each session is, for example, a lasting communication involving the exchange of many packets.

The configuration and transfer protocol being used, such as MTP, may define one or more transfer protocol entities, which are software modules useful for configuration and transfer; such as operations, result codes, object formats, data types, data sets, data file references, and the like. The configuration and transfer protocol, such as MTP, may further define how these transfer protocol entities may be used. When configuration or transfer is performed via a USB cable206or other network connection, one or more of these transfer protocol entities may be sent within discrete packets as part of a session.

The device200and the terminal202may share a storage medium208. In one implementation, the storage medium208is a removable read/write storage medium such as a memory card or magnetic disk. When the storage medium208is inserted into the device200or otherwise placed in communication with the device200, software running on the device200may access the contents of the storage medium208. Likewise, when the storage medium208is inserted into the terminal202or otherwise placed in communication with the terminal202, software running on the terminal202may access the contents of the storage medium208. The storage medium208may be formatted with a file system210that allows individual files to be created, read, written, or deleted. Software running on both the device200and the terminal202may implement support for the file system210, providing access to files stored on the storage medium208to both the device200and the terminal202.

The storage medium208may be routinely moved back and forth between the device200and the terminal202. In this case, the storage medium208may be formatted in such a way that software running on both the device200and the terminal202can access and modify information in files carried on the storage medium208. When the device200and the terminal202communicate by modifying files stored on the storage medium208, the storage medium208can be treated as a network connection.

As discussed above, when a network connection is used for configuration or transfer, a session is established, including one or more discrete packets sent over a USB cable206or other network connection. The packets may included transfer protocol entities; such as operations, result codes, object formats, data types, data sets, data file references and the like; that are defined by MTP or another configuration and transfer protocol.

Similarly, when configuration or transfer is performed via a storage medium208rather than a network connection, these transfer protocol entities may be used in a like fashion, to carry out device configurations or transfers. Instead of sending these transfer protocol entities within discrete packets over USB cable206or other network connection, the transfer protocol entities may be recorded within a device file212on the storage medium208. The information stored in the device file212may be recorded, for example, as a byte stream. The device file212may include all the information that would be transmitted during session, and the device file212may therefore be said to “represent” a session. In one implementation, all the transfer protocol entities, header information, and other information that would be communicated between the device200and the terminal202during a session are recorded into the device file212.

As the storage medium208is passed between the device200and the terminal202, information is passed between the device200and the terminal202, allowing for bi-directional communication. The device file212may record the transfer protocol entities sent in either direction, including packet “headers” that describe where the packet originated (for example, from the device200or the PC202) and the packet's destination. Likewise, the device file212may include other packet header information, such as sequence numbers, session identifiers, transaction identifiers, etc. that may be used to represent a complete session. A device file212can be viewed as a “serialized” session between one device200and one terminal202, in the sense that the information in a device file212is sufficient to construct a session that would have the intended effects on both the device200and the terminal202.

When the storage medium208includes a device file212representing a session, the storage medium208may be treated in some instances as a locally connected device. For example, programs, protocols, and data structures that are used to transfer information to and from locally connected devices may be utilized. As a particular example, the Windows operating system may use a device stack to transfer information to and from locally connected devices. The device file212representing a session allows the operating system to communicate with the device using a device stack.

FIG. 3is a block diagram illustrating an overview of a system in accordance with an embodiment of the present invention. As shown inFIG. 3, a terminal202may be configured to receive a storage medium208, such as a memory card or magnetic disk, via an input300, such as a card slot, disk drive, or the like. The storage medium208may be used, for example, to communicate with a device (not shown inFIG. 3) by means of passing the storage medium208back and forth between the terminal202and the device.

The terminal202may include a content application301that communicates with the device via the storage medium208. For example, in one implementation, the content application301may be a digital media player configured to communicate with a personal music player device. In this case, the content application301is configured to transmit media files to, or receive media files from, the personal music player. In another implementation, the content application301may be an application for storing and manipulating photographs. In this case, the content application301may be configured to receive photographs from, or transmit photographs to, a camera device. Other implementations including other content applications301, other content types, and other devices are possible.

The terminal202also includes, for example, an operating system302. The operating system302may be configured to communicate with the device via the storage medium208.

When the storage medium208is inserted into the input300, a device stack304may be created. In one implementation, the device stack304is created by the operating system302. The device stack304is, for example, software that is configured to facilitate communication by simulating a connection to the device.

In order to create the device stack304, device parameters306may be read from the storage medium208and stored in the terminal202. The device parameters306may be, for example, parameters specifying properties or attributes of the device, or otherwise describing the device. The device parameters306may include such information as the type of device, the type of content accepted by the device, the compression schemes used by the device, available memory on the device, Digital Rights Management information for the device, and the like. The device parameters306may be written to the storage medium, for example, by the device during formatting, as discussed further hereinbelow with reference toFIG. 5.

In order to create the device stack304, a virtual layer308may be created, for example, based on the device parameters306. In one implementation, the virtual layer308simulates the operation of the device. The combination of the device file212and the virtual layer308may be said to comprise a “virtual device.” The operation of the virtual device may be such that, from the perspective of the terminal202, the device appears to actually be connected to the terminal202.

The device stack may also contain a driver312. The driver312is, for example, a software module configured to communicate between the storage medium208and the content application301or the operating system302. In one implementation, the driver312receives a device file212from the storage medium208or otherwise accesses the device file212on the storage medium208. The driver312may also receive information and/or instructions from the content application301and/or the operating system302. Based on the information in the device file212, the information received from the content application301, and/or the information received from the operating system302, the driver212determines whether content should be transmitted from the device file212to the terminal202, and whether content should be transmitted from the terminal202to the device file212.

If the driver312determines that content should be written from the device file212to the terminal202, the driver312retrieves the content from the device file212. The driver312then determines whether any action should be taken on the content. The driver312determines whether action should be taken on the content, for example, by examining the virtual layer308, the content application301, and/or the operation system302. Examples of action taken on content include, for example, compressing the content, adding metadata to the content, performing DRM functions associated with the content, or the like. If action should be taken on the content, the driver312performs such action, for example, by examining the virtual layer308. In performing action on the content, the driver312may communicate with one or more DRM engines314. After action is taken on the content, the modified content may be stored, for example, to a database316. One or more transfer protocol entities indicating the operations that occurred, such as transfer protocol entities indicating that the content was received, modified, and/or stored may be written to the device file212.

If the driver312determines that content should be written from the terminal202to the device file212, the driver312retrieves the content, for example, from the database316, the content application301, or another location within the terminal202. The driver312then determines whether any action should be taken on the content. The driver312determines whether action should be taken on the content, for example, by examining the virtual layer308, the content application301, and/or the operating system302. Examples of action taken on content include, for example, compressing the content, adding metadata to the content, performing DRM functions associated with the content, or the like. If action should be taken on the content, the driver312performs such action, for example, by examining the virtual layer308. In performing action on the content, the driver312may communicate with one or more DRM engines314. After action is taken on the content, the modified content may be written, for example, to the device file212. The modified content is stored, for example, as a bit stream in the device file212. The modified content may be stored, for example, in conjunction with header data, transfer protocol entities, or other data.

Because content may be modified on the terminal202, the content stored in the device file212may be matched to the stream parameters, DRM model, and other expectations of the device. This may result in a smooth user experience that allows playback or other content consumption on the device with little or no input required from a user.

An example explaining the system from end to end is as follows: A storage card may be used as a means to connect two or more devices that would otherwise never be directly connected. These devices understand a common communication protocol, such as MTP as an example. A set of protocol operations can be serialized, or saved to a file that is stored on the removable storage medium, such as a compact flash memory card. One such example of a session is a mechanism for explaining the types of files that a device may support. For example, a particular device that only supports the transfer of photos may record to its device file on its removable storage that only photos are understood by the device. When this removable storage is directly inserted into a terminal, the terminal would parse the device file and then instantiate a device stack with an extra virtual layer bound to the device file that emulates the actual device. As such, the terminal believes it is directly communicating with the device and will determine that only photos can be transferred to/from the device. The terminal may then choose, for example, to transfer a photo to that virtual device. This operation will result in another device file on the removable storage that indicates that a new object is being created on the device, and then the point to the actual photo file that was saved to the removable storage. When this removable storage is then inserted back into the device, the device will read the new device file that was created by the terminal and conclude that a new photo file was added and the device file explains the attributes of this new photo file. Examples of some attributes, or metadata could include, the size of the file, the name of the file, the date/time the file was transferred, etc. This example is merely illustrative and those skilled in the art will appreciate that many other implementations and applications are possible.

In one implementation, a plurality of devices may use the same storage medium208. In this case, each device may create a separate device file212. In this implementation, each device file212may include a device identifier, such as, for example, a unique device identification string. Details of such an implementation will be described further with reference toFIG. 5.

FIG. 4is a flowchart illustrating a method for communicating with a device. As shown inFIG. 4, the method may begin in step400, wherein a terminal may receive a storage medium. For example, the storage medium may be inserted into a slot or disk drive, or otherwise placed in communication with the terminal.

The method may continue in step402, wherein a terminal may obtain device parameters from the storage medium. For example, the storage medium may be inserted into an input such as a slot or disk drive, and the device parameters may be obtained.

The method may continue in step404, wherein a device stack may be built. The device stack may be, for example, software that is configured to facilitate communication by simulating a connection to the device. The device stack may be built, for example, by the operating system based on the device parameters obtained from the storage medium The device stack may include, for example, a virtual layer configured to simulate the operation of the device and a driver configured to communicate between the storage medium the operating system or a content application.

In step406, session information may be read from the storage medium. Session information may be read406, for example, from a device file on the storage medium. Reading session information406may include, for example, receiving content from the storage medium to the terminal, receiving requests for content from the storage medium, or receiving any other information that might be communicated during a session.

In step407, action may be taken on the content. In an implementation of the invention, action taken on the content is performed via the terminal. In this implementation, the terminal is therefore responsible, for example, for actions such as compressing the content, adding metadata to the content, performing DRM functions associated with the content, or performing other actions to facilitate communication between the device and the terminal.

Taking action on the content407may be performed, for example, by the device stack, in communication with a DRM engine, an operating system, and/or a content application. If content is received in the session information in step406, taking action on the content may include processing the received content and storing it in the terminal. For example, metadata may be added or DRM functions may be performed prior to storing received content in the terminal. If a request for content is received in step406, taking action on the content may include processing content to be transmitted to the device. For example, content may be retrieved from local storage on the terminal, and the content may be compressed or DM functions may be performed in preparation for transmitting the content to the device.

In step408, session information may be written to the storage medium. Writing session information includes, for example, storing session information, including one or more media transfer entities, as a byte stream in the device file. The session information written to the storage medium may include content to be transferred to the device. The session information written to the storage medium may further include an indication of the content transfer, a request for further content, session information, header information, or other information used to represent a session.

In step410, the storage medium may be removed from the terminal. For example, the storage medium may be removed from a card or disk drive, or otherwise withdrawn from communication with the terminal.

FIG. 5is a flowchart illustrating a method for communicating with a terminal. As shown inFIG. 5, the method may begin in step500, wherein a device may receive a storage medium. For example, the storage medium may be inserted into a slot or disk drive, or otherwise placed in communication with the device.

The method may continue in step502, wherein it is determined whether the storage medium has been formatted for the device. In one implementation, the device determines whether or not will determine whether the storage medium has been formatted for the device, for example, by detecting the presence of device-specific information on the storage medium. For example, the device may detect the presence of a device file, device parameters, a device identifier, or other information on the storage medium.

If the storage medium has not been formatted for the device, in step504, the device may format the storage medium. Formatting the storage medium may include, for example, creating a device file, storing a device identifier, and storing device parameters. The method may continue in step508.

If it is determined in step502that the storage medium has been formatted for the device, the method may continue in step506, wherein session information may be read from the storage medium. Session information may be read506, for example, from a device file on the storage medium. Reading session information506may include, for example, transferring content from the storage medium to the device.

In step508, session information may be written to the storage medium508. Writing session information includes, for example, storing session information, including one or more media transfer entities, as a byte stream in the device file. The session information written to the storage medium may include content to be transferred to the terminal. The session information written to the storage medium may further include. An indication of the content transfer, a request for further content, session information, header information, or other information used to represent a session.

In an implementation of the invention, action taken on the content is performed via the terminal, so that the device can write content directly to the device file. In this implementation, the device is therefore not responsible, for example, for actions such as compressing the content, adding metadata to the content, performing DRM functions associated with the content, or performing other actions to facilitate communication between the device and the terminal.

In step510, the storage medium may be removed from the device. For example, the storage medium may be removed from a card slot or disk drive, or otherwise withdrawn from communication with the device.

In implementations of the invention, a plurality of devices may use the same storage medium208. In this case, each device may create a separate device file212. In this implementation, each device file212may include a device identifier, such as, for example, a unique device identification string.

When the storage medium is placed in communication with the terminal, the terminal searches the storage medium for a target device file to use to communicate with a device. In one implementation, if more than one device file is found, a user may be contacted to determine which device file to use. In another implementation, a decision made be used based on rules, such as user-selected preferences. For example, such a rule may state that the device that has last been used should be communicated with. As another example, such a rule may state that the first device file encountered should be used. Other rules and schemes for communicating with storage media containing multiple device files are possible.

As target devices are frequently constrained, the large quantity of media content on the storage card may be organized to allow for improved device operation. To achieve this, an accelerator can be used in conjunction with the invention. For example, an accelerator may write an accelerator file to the storage medium, for example, as media content storage is being completed. The accelerator file may provide content metadata that may be accessed, for example, by a user interface for the device. An accelerator scheme used in conjunction with the present invention may be, for example, independent of the block file system which is used to format the card.

In some implementations, such as in the case of a device that is not capable of recording media content, an accelerator file such as, for example, a device-optimized metadata database, may be used. In various implementations, other accelerators may be used.

Implementations provide a coherent user experience by providing the terminal an accurate snapshot of the device parameters at the time when it runs the content. Implementations provide a standard scheme of encoding the device parameters, which allows the terminal to enable optimal device operation when transfer is done via a storage medium. The terminal can therefore create an accelerator file for use by the device, as well as taking action on media content to prepare the media content for the device.

While particular embodiments of the invention have been illustrated and described in detail herein, it should be understood that various changes and modifications might be made to the invention without departing from the scope and intent of the invention. The embodiments described herein are intended in all respects to be illustrative rather than restrictive. Alternate embodiments will become apparent to those skilled in the art to which the present invention pertains without departing from its scope.