Remotely accessing protected files via streaming

A source device permits a user of a remote device to access a protected file on the source device when the user of the remote device has a right to access the protected file. The user locates the protected file on the source device using the remote device and accesses the protected file using a media player on the remote device. The media player constructs a path by which the source device streams the protected file. The remote device responds to an authentication request from the source device that the user of the remote device has a right to access the protected file. The user is authenticated to confirm that the user of the remote device has a right to access the protected file. The protected file is streamed to the remote device via a path constructed by the remote device.

BACKGROUND

Embodiments of the present invention relate to the field of media players for remotely accessing protected files. In particular, embodiments of this invention relate to enabling a scenario in which a user on a remote device can manage/navigate/search for the user's files on a source device using standard tools and, upon invocation to play a particular file on a source device, offer up a secure, streaming URL by which the source device provides the file to the remote device.

Using traditional file operations, a protected file such as a file controlled by digital rights management (DRM) can only be played on a device, such as a PC, that hosts its license. For example, when a file is to be played by WINDOWS Media Player (WMP), WMP opens the file and tries to play it. In that process, if the file is found to have DRM, then the DRM subsystem is invoked to validate the license. In absence of a valid license on the PC executing WMP, an attempt is made to acquire one for the PC. Because DRM content generally has a small limit as to the number of machines (e.g.: 3) that can be licensed, access by a remote PC is limited. If the file came from a source PC, the source PC likely already has a license. Reuse of the source license is one preferable solution.

At least some operating systems, such as WINDOWS®, have a media streaming service capability such as “WINDOWS® Media Connect” (WMC). WMC permits streaming of content from one device to another, e.g., PC to PC, in a way that does not require stringent licensing rules. This streaming leverages streaming media protocols. These protocols are geared towards playback of content and do not generally permit file operations such as metadata updates, content updates, etc. The content may additionally be encrypted when in transit from one device to another such that only the requesting device can decrypt the content. The content is generally considered “protected” when streamed whereas it is deemed very vulnerable when accessible via file copy protocols (SMB).

While nearly any transfer protocol, such as SMB, HTTP, RTSP, or MMS can be used for both streaming and file copying, copyright holders of the media frequently desire to require the addition of encryption to the protocol as there are numerous programs that create file copies from the presumably “streaming” protocols listed above.

In order to protect the copyright holders of the media, in many cases, contracts stipulate streaming and/or encryption as a mode of remote access.

WINDOWS® users make heavy use of the SMB protocol as part of common applications like the WINDOWS® Explorer shell application. This application lets a user look at files anywhere on their network and manage them. Media that is protected by digital rights management (DRM) may not be played in this scenario for the above cited reasons.

SUMMARY

Embodiments of the invention include an access which has a security level protocol (e.g., a SMB protocol, a non-SMB protocol, NFS, or the like). In an embodiment, the invention includes streaming a protected file on a path in a secure manner. Embodiments of the invention apply to any SMB aware devices, many of which exist because of the open source SMB packages, such as a SAMBA server.

Alternatively, embodiments of the invention provide secure access of DRM encrypted content (e.g., multimedia files) by having a source device which looks to a remote device to authenticate the user of the remote device. In addition, embodiments of the invention construct the protocols to find the DRM encrypted content, which protocols are different from the protocols used to stream the content.

Alternatively, embodiments of the invention may comprise various other methods and apparatuses.

DETAILED DESCRIPTION

Referring first toFIG. 1, a block diagram is presented to illustrate an exemplary embodiment of a remote device such as remote PC102accessing a protected file such as a digital rights management protected file104on a source device such as a source PC106. PC102is referred to as remote because it is separate in some way from the source PC106. In this illustration, it is assumed that a user108of the remote PC102has the right to access DRM-protected file104.

In one embodiment, the user of remote PC102would initially identify (by browsing or other review) one or more files on the source PC106, as indicated by arrow110. Once a desired DRM-protected file104is identified by the user108via the remote PC102, the user108would invoke a media player112to access the desired file104via a protocol such as SMB (service message block) at114. Next, the media player112constructs a URL at116to interface with a streaming software module118of a media delivery application (MDA)120via WINDOWS® Media Connect (WMC)122of the source PC106. In one embodiment, the MDA120may be a component or module of an application, an application, software, an application program, or a set of computer-executable instructions that delivers or assists in delivering media files from the source PC106to the remote PC102. In one embodiment, WMC122is an application or a communication module of the source PC106that interacts with, hosts, and/or controls the MDA120.

In one example, for every request received from user108, MDA120generates events such as an authentication event. In one embodiment, this authentication or authorization event contains the logical URL, as well as the complete request from the media player112. WMC122translates the logical URL to the physical path of the file. In another embodiment, for some logical URLs, WMC122does not need to take any action and may simply return success to the MDA120. Alternatively, for other logical URLs, WMC122determines whether any request from remote PC102is authorized to access the file, (e.g., file104). If the logical URL is generated from a UNC path, such as a path exposed by the SMB server on source PC106, WMC122then needs to authenticate the user108before WMC122allows MDA120to stream the file104to the media player112.

In one embodiment, when a user authentication is required, WMC122passes the challenge-response from the authentication event to the authentication module124. The authentication module124verifies whether the challenge-response is present in the authentication event. If the challenge response is absent, the authentication process results in an ACCESS_DENIED error and user access is denied. In another embodiment, the authentication module124generates an authentication challenge for the media player112. In this embodiment, WMC122passes this challenge to MDA120and MDA120would fail the request from the media player112and passes the authentication challenge to the media player112. The media player112may respond to the authentication challenge by sending an authentication challenge-response. This challenge-response essentially represents the user's credentials of media player112. The format and/or form of the challenge-response may vary depending on the authentication protocol being used. Upon receiving a new request including the challenge-response from media player112, MDA120generates a similar authentication event in response to the new request, albeit this time the challenge-response is included in the request from media player112, and passes the challenge-response with the event. WMC122removes the challenge-response from the event and passes the event to the authentication module124which determines whether to deny or grant the request. When authentication module124successfully authenticates user108, authentication module124generates an access token which WMC122may use later to authorize the user's access to the requested content (e.g., file104). It is to be noted that depending upon the authentication scheme being used, multiple round trips from media player112to MDA120may be required to authenticate media player112.

In another embodiment, once the request succeeds, MDA120generates an authorization event to the WMC122. WMC122next uses the access token acquired during the authentication event to verify the user's rights to playback the protected content (e.g., file104). If the user doesn't have the right to access the content, WMC122may fail the authorization event. In such case, MDA120would fail the request from media player112with a “Forbidden” error.

Referring next toFIG. 2, an exemplary diagram is presented illustrating chronological operation of an embodiment of the invention. In one embodiment, consider a scenario where a remote PC202is trying to play a protected file on a source PC204. The remote PC202is running a media player (e.g., WINDOWS® Media Player or other device) at206. The source PC204is running a media streaming server (e.g., a media delivery application—MDA) as well as media sharing service at208. The source PC204is sharing media via its UNC shares (e.g., over an SMB protocol) at208. A user on the remote PC202browses or searches media on the source PC204on the UNC shares via SMB at210. The user invokes a PLAY action with respect to one of the media files and the media player is asked to play the file via an auto-play association at212.

When a media player needs to stream content discovered on an SMB path (\\serverSMB\folder\ . . . ), the media player constructs a particular URL (e.g., an SMB-HME Streaming URL) and uses the constructed URL for streaming the content at214. This constructed URL is directed at the MDA, such as an MDA server on a server machine, exposing the SMB path, at216. For example, the media player retrieves the path format from the source device by reading a new tag in a source (e.g., UPnP Media Server device document) which source device uses to specify which port to be used for transfer, such as RTSP. Next, the media player permanently constructs URL (i.e., hardcodes) some specific paths (described below) to stream the content. Embodiments of the URL take on the form of one of the following using either HTTP or RTSP protocol:

In the above URL embodiments, HTTP or RTSP streaming protocols are specified but the remainder of the URL is the same. Those skilled in the art will recognize other embodiments.

In another embodiment, the URL format may also be part of a device document or other source that the source device provides. In yet another embodiment, only the specific path may be part of a device document or other source that the source device provides.

At this point, at218, MDA begins to authenticate the user before passing back a stream to the media file or even acknowledging existence of the file. In one embodiment, authentication is done in the following sequence:

The media player attempts to stream from an SMB-HME Streaming URL

The MDA relies on the media connect function (e.g., WINDOWS® Media Connect (WMC)) to parse the URL at220. In one particular embodiment, the MDA generates an authentication event including a transformed URL (e.g., an SMB-HME streaming URL) into the WMC at220. In another embodiment, WMC parses and translates the SMB-HME streaming URL into a physical path and returns to MDA at220. In an alternative embodiment, the MDA relies on the media connect function to translate the URL passed by MDA in the authentication event at220into a physical path of the file. In this embodiment, the MDA generates an authentication event including a logical URL into the WMC at220. WMC parses and translates the SMB-HME streaming URL into a physical path. As such, the MDA does not need the physical path during the authentication event.

In one embodiment, the authentication event is a data structure or an interface that is used between MDA and WMC, and other data structure or interface implementations may be used without departing from the scope of the present invention. As an example, the exemplary code below illustrates a series of requests exchanged between WMP and MDA for protected as well as unprotected content access.

Physical URL:C:\users\username\music\asf\artist\title.wmaThe \\serverSMB\share gets translated to c:\users\username\music

It is to be understood that while the exemplary requests illustrated above use the control protocol DLNA Http and the authentication protocol Negotiate, other protocols, compliant control protocols, and/or authentication protocols may be used without departing from the scope of the invention.

The MDA relies on the WMC to authenticate the remote user's permission to access this URL at222(see also the exemplary requests illustrated above). For example, in one embodiment, the MDA provides the authentication event including the SMB-HME streaming URL to the WMC and, in response, the WMC generates an appropriate challenge via a security support provider interface (SSPI) or other interface and returns the challenge to the MDA. The MDA then sends the challenge to the media player at222. The media player responds to the challenge and, as a result, an access token is obtained by the MDA at224. For example, the access token may be a WINDOWS® handle that represents a specific user. This handle may be passed or transmitted to other APIs to validate the user and/or to impersonate a user. Other types of identification tokens or keys that represent or identify the user may be used without departing from the scope of the present invention. The WMC successfully authenticates the user at226. In addition, MDA generates authorization event to WMC and WMC confirms whether user has access to the content. If user has the access to the content, WMC passes the physical location of the file to MDA at226. Thus, the MDA has determined that the stream request is from an authenticated user that can access that file and permits access to the protected file and MDA streams out content based appropriately to the media player at228.

In one embodiment, this sequence illustrates that MDA is capable of consuming a UNC path and rendering a stream while validating the user via existing technologies. In embodiments of a WINDOWS® Media Player client, the authentication protocol may be SSPI because it will make use of the user's credentials and validate precisely that the user has access to the file in question.

In one embodiment in a WINDOWS® environment, WINDOWS® Explorer launches the registered application for the file extension. In the case of WINDOWS® Media Audio or WINDOWS® Medial Video, the application is WINDOWS® Media Player (WMP). Given a UNC path from WINDOWS® Explorer, WMP:i. Validates the logged on user has access to the UNC path;ii. Resolves the UNC path to a streaming URL; andiii. Opens the streaming URL for playback.

If any edits are performed on the data associated with the file104provided via the streaming URL, the SMB path may be used to affect any changes. This permits any PC user that can prove access to a SMB-accessible file on a source device to stream the file from the source device to a remote device without requiring license acquisition on the remote device. For example, user108may go through206to212for streaming content that does not require a license, such as unprotected content. In addition, at216, URL and request for a streaming license is directed at MDA exposing SMB path. This request may include a certificate proving the device's robustness and adherence to the rules provided in any license subsequently provided. The user108may go through218to226for streaming content that does not require a license. The MDA verifies certificate or other information provided in step216and returns a license and key that allows the media player to decrypt and play the content subsequently transferred.

Thus, in one embodiment, given a UNC path, playback of a file protected by DRM is enabled without requiring that the new PC log into a service or reacquire a license from other than the computer hosting the UNC path. This embodiment enables a user of the WINDOWS Shell/Explorer to freely browse or search and play music protected by DRM in their home. Further, any added security risk may be minimized by offering another method of accessing files. Although the “attack surface” gets larger, no paths of lesser security have been added, e.g., a file a given user could not see/hear before is no more exposed now.

In operation in one embodiment, a computer130such as illustrated inFIG. 3executes computer-executable instructions such as those illustrated above to function as either a remote device or a source device.

FIG. 3shows one example of a general purpose computing device in the form of a computer130. In one embodiment of the invention, a computer such as the computer130is suitable for use in the other figures illustrated and described herein. Computer130has one or more processors or processing units132and a system memory134. In the illustrated embodiment, a system bus136couples various system components including the system memory134to the processors132. The bus136represents one or more of any of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus.

The computer130typically has at least some form of computer readable media. Computer readable media, which include both volatile and nonvolatile media, removable and non-removable media, may be any available medium that may be accessed by computer130. By way of example and not limitation, computer readable media comprise computer storage media and communication media. Computer storage media include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. For example, computer storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store the desired information and that may be accessed by computer130. Communication media typically embody 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 include any information delivery media. Those skilled in the art are familiar with the modulated data signal, which has one or more of its characteristics set or changed in such a manner as to encode information in the signal. Wired media, such as a wired network or direct-wired connection, and wireless media, such as acoustic, RF, infrared, and other wireless media, are examples of communication media. Combinations of any of the above are also included within the scope of computer readable media.

The system memory134includes computer storage media in the form of removable and/or non-removable, volatile and/or nonvolatile memory. In the illustrated embodiment, system memory134includes read only memory (ROM)138and random access memory (RAM)140. A basic input/output system142(BIOS), containing the basic routines that help to transfer information between elements within computer130, such as during start-up, is typically stored in ROM138. RAM140typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit132. By way of example, and not limitation,FIG. 3illustrates operating system144, application programs146, other program modules148, and program data150.

The computer130may also include other removable/non-removable, volatile/nonvolatile computer storage media. For example,FIG. 3illustrates a hard disk drive154that reads from or writes to non-removable, nonvolatile magnetic media.FIG. 3also shows a magnetic disk drive156that reads from or writes to a removable, nonvolatile magnetic disk158, and an optical disk drive160that reads from or writes to a removable, nonvolatile optical disk162such as a CD-ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that may be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, and the like. The hard disk drive154, and magnetic disk drive156and optical disk drive160are typically connected to the system bus136by a non-volatile memory interface, such as interface166.

The drives or other mass storage devices and their associated computer storage media discussed above and illustrated inFIG. 3, provide storage of computer readable instructions, data structures, program modules and other data for the computer130. InFIG. 3, for example, hard disk drive154is illustrated as storing operating system170, application programs172, other program modules174, and program data176. Note that these components may either be the same as or different from operating system144, application programs146, other program modules148, and program data150. Operating system170, application programs172, other program modules174, and program data176are given different numbers here to illustrate that, at a minimum, they are different copies.

A user may enter commands and information into computer130through input devices or user interface selection devices such as a keyboard180and a pointing device182(e.g., a mouse, trackball, pen, or touch pad). Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are connected to processing unit132through a user input interface184that is coupled to system bus136, but may be connected by other interface and bus structures, such as a parallel port, game port, or a Universal Serial Bus (USB). A monitor188or other type of display device is also connected to system bus136via an interface, such as a video interface190. In addition to the monitor188, computers often include other peripheral output devices (not shown) such as a printer and speakers, which may be connected through an output peripheral interface (not shown).

The computer130may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer194. The remote computer194may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to computer130. The logical connections depicted inFIG. 3include a local area network (LAN)196and a wide area network (WAN)198, but may also include other networks. LAN136and/or WAN138may be a wired network, a wireless network, a combination thereof, and so on. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets, and global computer networks (e.g., the Internet).

When used in a local area networking environment, computer130is connected to the LAN196through a network interface or adapter186. When used in a wide area networking environment, computer130typically includes a modem178or other means for establishing communications over the WAN198, such as the Internet. The modem178, which may be internal or external, is connected to system bus136via the user input interface184, or other appropriate mechanism. In a networked environment, program modules depicted relative to computer130, or portions thereof, may be stored in a remote memory storage device (not shown). By way of example, and not limitation,FIG. 3illustrates remote application programs192as residing on the memory device. The network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

Embodiments of the invention may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include, but are not limited to, routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types. Embodiments of the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

An interface in the context of a software architecture includes a software module, component, code portion, or other sequence of computer-executable instructions. The interface includes, for example, a first module accessing a second module to perform computing tasks on behalf of the first module. The first and second modules include, in one example, application programming interfaces (APIs) such as provided by operating systems, component object model (COM) interfaces (e.g., for peer-to-peer application communication), and extensible markup language metadata interchange format (XMI) interfaces (e.g., for communication between web services).

The interface may be a tightly coupled, synchronous implementation such as in Java 2 Platform Enterprise Edition (J2EE), COM, or distributed COM (DCOM) examples. Alternatively or in addition, the interface may be a loosely coupled, asynchronous implementation such as in a web service (e.g., using the simple object access protocol). In general, the interface includes any combination of the following characteristics: tightly coupled, loosely coupled, synchronous, and asynchronous. Further, the interface may conform to a standard protocol, a proprietary protocol, or any combination of standard and proprietary protocols.

The interfaces described herein may all be part of a single interface or may be implemented as separate interfaces or any combination therein. The interfaces may execute locally or remotely to provide functionality. Further, the interfaces may include additional or less functionality than illustrated or described herein.

The order of execution or performance of the methods illustrated and described herein is not essential, unless otherwise specified. That is, elements of the methods may be performed in any order, unless otherwise specified, and that the methods may include more or less elements than those disclosed herein. For example, it is contemplated that executing or performing a particular element before, contemporaneously with, or after another element is within the scope of the embodiments of the invention.

In view of the above, it will be seen that various embodiments of the invention are achieved and various advantageous results attained.