Patent Application
20070282846
Further features and advantages of the present invention will become apparent from the following detailed description, taken in combination with the appended drawings, in which:
It will be noted that throughout the appended drawings, like features are identified by like reference numerals.
The present invention provides system and methods that enable media-on-demand library to be partitioned to ensure secure access to assets of the media library. Embodiments of the present invention are described below, by way of example only, with reference to
The present invention provides for securing a media library of a media-on-demand (MoD) system by defining unique middleware instances for user groups. Users or clients that are part of a particular user group can only access content that has been registered with the associated middleware instance. The media library resides on a common media server which can service multiple middleware instances reducing hardware resources and administration costs. The media server may comprise a plurality of clusters, wherein each cluster comprises a plurality of hardware and software devices for storing the media.
A user/client can only request content from the associated middleware instance to which it is granted access. The middleware also provides the interface to the MoD system for the user/client and controls access to content. In addition, middleware facilities features such as network monitoring and billing.
When a request for content from the user/client is received at the middleware instance, the middleware requests entitlement from an entitlement manager. The entitlement manager may include an encryption engine if required. The encryption & entitlement manager provides credentials or decryption keys to the user so that the content can be decrypted. The decryption key for a given media asset is common for all the user groups. The entitlement would generally be common for all user groups, but in principle could be different for each user group. For example, user group 1 might be entitled to watch a movie, where as group 2 would be entitled to watch and record the movie. Once entitlement has been provided the user can then request that the content be streamed from the media server and decrypt the content. Entitlement and encryption have been identified as one system for illustrative purposes. A person of ordinary skill in the art would understand that entitlement and encryption may be implemented separately by various methods.
Multiple middleware instances are created dependent on the number of user groups defined by the administrator. Each middleware instance may correspond to a class of user with a different subscriptions, but have access to shared media servers, digital rights servers and authentication servers.
The media may be streamed to the user/client by any number of protocols such as Motion Picture Experts Group Transport Stream (MPEG-TS), Motion Picture Experts Group Program Stream (MPEG-PS), Hypertext Transfer Protocol (HTTP), Multimedia Message Service (MMS), Real Time Transport Protocol (RTP), Real Time Streaming Protocol (RTSP), Real Time Control Protocol (RTCP) or proprietary protocols for example Real Networks Real Data Transport (RDT) or Windows Media Advanced Streaming Format (ASF) depending on the system architecture.
It should also be understood that the media-on-demand system may be resident on a single network or have components distributed to other adjoining networks. For example, the media server 30 may be located on a different network separate from the encryption & entitlement manager 20. The media server 30 may comprise one or more clusters of hardware and software devices that may act together to store media and to deliver requested content.
Each of the middleware instances can access the shared resources of the system such as the encryption & entitlement manager 20 and media server 30. The users/clients 60 of the system only have access to the particular middleware #1, #2 or #3 (42, 44 & 46) instance associated with their associated user group providing control over the content that is available to the users.
Alternatively, the user/clients 60 may not be restricted to a single middleware instance but may be granted access different middleware instances to access different content types or content provider. The user/client 60 would log into a particular middleware instance to access content associated with the respective middleware instance.
Referring also to
The ingestion of the content into the MoD system must then be initiated by one of the middleware instances which can be determined by a various methods. For example, the lowest identified (numbered) middleware instance may be responsible for initiating content ingestion. The command may be provided as part of the metadata at step 303′ to middleware#346 or issued separately. The selected middleware, middleware#346, sends an ingest content message at step 305 to the encryption & entitlement manager 20.
Registration continues with each middleware instance then sends a request to the media source for the metadata associated with the content and the media source provides the metadata at steps 304 and 304′. It should also be understood that metadata may be provided alternatively by the administrator 50 directly rather than the media source either at steps 303 and 303′ or steps 304 and 304′.
The encryption & entitlement manager 20 creates entitlement policies for the specific content at step 306. Separate entitlement polices may be created for each middleware instances. The entitlement policy defines the rights period to access the content in addition to defining what can be done with the content such as recording or copying. The rights period may be a defined by parameters such as hours of availability, length of time that the content is available such as 24 hours or number of viewings allowed. For example, users/clients accessing middleware#244 may be able to only view the content, where as users/clients accessing middleware#346 may be able to view and record content which would require a different entitlement policy. Therefore, step 306 may receive additional requests from middleware#244 and middleware#346 prior to step 306 for creation of middleware specific entitlement policies.
Alternatively the administrator 50 may define the entitlement policies directly with the entitlement & encryption manager 20. In addition, the encryption & entitlement manager 20 may provide a more general entitlement to some or all of the media library, at some earlier time, such as when the user/client 60 logs into the middleware 40. In an embodiment, the middleware 40 can instruct the encryption & entitlement manager 20 to deliver appropriate entitlement information to the user/client 60, after the middleware 40 has approved the request for a particular media asset.
The middleware#346 then sends a request to the media source to send the content at step 307. The content is sent at step 308 to the encryption & entitlement manager 20. The media server 30 is then sent a request by the middleware#346 to ingest the content at step 309 and the encryption & entitlement manager 20 is requested to send the content at step 310 to the media server. The content is encrypted and sent at step 311 from the encryption & entitlement manager 20 to the media server 30. In another embodiment the encryption & entitlement manager 20, may be distributed or located after the media server 30. Content would then be encrypted as it is streamed in real-time to the user/client.
It should also be understood that the ingest content message may be sent from the middleware to the media source 10, as an instruction for the media source to push the content into the MoD system.
In this example the client/user may be part of a user group associated with middleware#244. Availability of the new content is then advertised to the user/clients 60 through the broadband network 55 by the middleware#244 by an update menu message at step 312 via a menu or directory update. The menu may be simply a directory displayed to the user of available content or take the form of a programming guide or searching interface.
Accordingly, the user/client associated with the middleware#346 that was used to ingest the content may now access the content; a user/client associated with the middleware#244 that ingested the metadata but was not used to ingest the content may now also access the content; but a user/client associated with middleware#142 will remain unaware of the content and will not be able to access or request the content.
At step 401 the client 60 must login to the middleware#244 to access the on-demand system. The client then sends a media request at step 402 to the middleware#244. The media request may be a request for a specific piece of content such as a video program. The middleware#244 authorizes the request at step 403. The authorization of the request may include communication with an authentication system (not shown). At step 404 the middleware 40 then sends an entitlement authorization to the encryption & entitlement manager 20. The encryption & entitlement manager 20 provides entitlement keys or certificates at step 405 which allow the user/client 60 to access and decode the requested content.
The entitlement may be defined for s specific period of time, for example allowing a program to be viewed for limited period, such as 24 hours. Entitlement may also include identification of what the user/client can do with the content such as playback, record, copy or moved to other devices.
The user/client 60 can then send a streaming request at step 406 to the media server 30 which will then stream the required content to the user/client 60 at step 407. If the user/client 60 requests content from a middleware instance which is it not defined as part of the user group, for example middleware#142 or middleware#346, the request will be denied. The request to access content cannot be spoofed because middleware#142 does not know about the content an cannot generate a legal send entitlement request to the encryption & entitlement manager 20 to access the content.
The user/client 60 may unlock or access the content only after reception of associated certificate or key sent by the encryption & entitlement manager. The certificate or key is only sent when the encryption & entitlement manager 20 is instructed to do so by the associated middleware. The middleware effectively controls access to the content as the respective user groups are only aware of content registered with the respective middleware instance. Flags or permissions do not have to directly associated with the content allowing the content stored on the media server to be administered more easily from a shared resource.
In another embodiment, the user/client 60 requests for content at step 402 made via the middleware instance may be performed by securing dialogs facilitated by the encryption & entitlement manager 20 or an authentication server (not shown). Further, the middleware instances 42, 44, 46 and the encryption & entitlement manager 20 may be associated with an authentication server (not shown). The authentication server would be used to secure the entitlement authorization message at step 404. Thus, advantageously, a chain of trust is established: the content is secured by certificates and keys held in the encryption & entitlement manager 20; the user/client 60 is authenticated with the authentication server to make content requests 402; the middleware instances are authenticated with the authentication server to send entitlement requests 404; and the content may be unlocked only by the certificates and keys sent by the encryption & entitlement server 20. In this manner, the send entitlement message 404 cannot be spoofed by an unauthorized user or hacker.
In an alternative embodiment, multiple administrators 50 may be defined for the MoD system. Each administrator is involved in the flow only for assets for which they are authorized to manage. Unique media sources may be associated with individual administrators and middleware instances. The middleware instances may also be controlled by multiple administrators to provide access to the media assets dependent on the network configuration. The embodiment would be applicable where specific administrators are directly responsible for specific content providers available to the users of the MoD system.
The embodiments of the invention described above are intended to be illustrative only. The scope of the invention is therefore intended to be limited solely by the scope of the appended claims.
