At least some embodiments as described herein relate generally to providing, authorizing and monitoring the distribution of media content within a subscriber domain of devices.
The present description includes material protected by copyrights, such as illustrations of graphical user interface images. The owners of the copyrights, including the assignee, hereby reserve their rights, including copyright, in these materials. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the patent and trademark office file or records, but otherwise reserves all copyrights whatsoever. Copyright Digital Keystone, Inc. 2012.
Advances in multimedia technology provide various ways to deliver multimedia content to a user. For example, video on demand (VOD) or audio and video on demand (AVOD) are systems which allow users to select and watch/listen to video or audio content on demand on televisions and personal computers.
Television VOD systems either stream content through a set-top box, a computer or other device, allowing viewing in real time, or download it to a device such as a computer, digital video recorder (also called a personal video recorder) or portable media player for viewing at any time. The majority of cable- and telco-based television providers offer both VOD streaming, including pay-per-view and free content, whereby a user buys or selects a movie or television program and it begins to play on the television set almost instantaneously, or downloading to a DVR rented from the provider, or downloaded onto a pc, for viewing in the future.
Internet television, using the Internet, is an increasingly popular form of video on demand. Some video distribution systems, for example, Netflix, Inc., provides on-demand media over the Internet to a subscriber.
Some other video distribution systems, for example, YouTube provide a video-sharing website, on which users can upload, view and share videos. A user can search for a video on the video-sharing website and obtain as a result of search a list of uniform resource locators (URLs). The user can select one of the URLs and start watching the content. The video distribution system, such as YouTube can distribute only the content from a site that is controlled by the operator of this system.
Existing media player computer programs, for example iTunes, are used for playing, downloading, and organizing digital music and video files on desktop or laptop computers. For example, iTunes can connect to the iTunes store to purchase and download music, and other media content. iTunes, however is not being able to transfer media from one type of a portable device to another. The existing media player programs, such as iTunes, are architected for a uniform population of player devices. For example, iTunes cannot play on a Samsung TV, on a Sony tablet, or on a Nokia phone.
Existing video distribution systems, for example, YouTube and Netflix do not customize the content navigation. They do not include local content sources and do not modulate their offering based on player profiles. The existing video distribution systems do not manage geo-localization at a home domain. The existing video distribution systems integrate a single content contribution network and do not offer a choice of content distribution path options.
Currently content distribution, authorization and monitoring functions are embedded at a content server source such as YouTube or Netflix, within a content distribution network (CDN), and/or within proprietary software in media players such as iTunes.
Existing vertically integrated video distribution system, such as iTunes, only know how to register and authorize single-technology devices. The existing video distribution systems do not manage devices of different technologies or digital rights management (DRM) capabilities. Additionally, the existing video distribution systems do not manage assets with different distribution rules. Furthermore, the existing video distribution systems do not manage domains with different entitlement rights.
Exemplary embodiments of methods and apparatuses to provide one or more subscriber domain management services are described. A subscriber domain is defined as an association of one or more content source (“gateways”), and one or more content sink (“subscriber device”), one or more entitlements for a class or a specific media asset, and one or more domain rights. Gateways can be provisioned for a domain by an operator. In at least some embodiments, a gateway can be shared across multiple domains in an access network or over the Internet (“network gateway”). In at least some other embodiments, a gateway is dedicated to an individual domain, such as a gateway installed within the home (“home gateway”).
In at least some embodiment, a gateway can be accessed through multiple content distribution paths, which can be identified by one or more URLs, or one or more IP addresses.
In at least some embodiment, the media asset can be offered under one or more streaming formats, one or more file download options, or a combination thereof. The media asset can be video, music, application, game, or a combination thereof.
In at least some embodiments, a domain management service includes catalog adjustment at a server to provide media content within a subscriber domain.
In at least some embodiments, another domain management service leverages the data associated to the subscriber domain to authorize the distribution of media content within the devices of the domain based on the established distribution paths with the associated gateways and the capabilities of the devices.
In at least some embodiments, another domain management service includes monitoring and recording the distribution of media content to the devices of the domain with enough details to enable domain analytics.
In at least some embodiments, some of the subscriber domain details are provided by the associated gateways. Catalog up-loads, content distribution path determination results and playback state transition reports are recorded.
In at least some embodiments, some of the subscriber domain details are provided by the registered players. Media request transactions between a DRM license server and a client device associated with a subscriber domain are recorded.
Other features as described herein will be apparent from the accompanying drawings and from the detailed description which follows.
The embodiments as described herein are illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements.
The embodiments will be described with references to numerous details set forth below, and the accompanying drawings. The following description and drawings are illustrative of the embodiments and are not to be construed as limiting. Numerous specific details are described to provide a thorough understanding of the embodiments as described herein. However, in certain instances, well known or conventional details are not described in order to not unnecessarily obscure the embodiments in detail.
Reference throughout the specification to “at least some embodiments”, “another embodiment”, or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least some embodiments as described herein. Thus, the appearance of the phrases “in at least some embodiments” or “in an embodiment” in various places throughout the specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
Exemplary embodiments of methods and apparatuses for domain management are described. In at least some embodiments, the objective of domain management is to provide, authorize and monitor the distribution of subscriber-entitled assets, from the applicable gateways and gateway content distribution paths, to registered subscriber devices without requiring any specific software cooperation with the gateways and the subscriber devices.
At least one embodiment as described herein, defines a method for distributing premium video content within a subscriber domain of devices. In one embodiment, a subscriber domain comprises an association of a) one or more gateways, b) one or more entitlements, c) one or more domain rights applicable to the subscriber domain and d) a set of registered player devices. In one embodiment, a domain is associated with a subscriber. In one embodiment, multiple subscribers are associated with multiple domains.
In at least some embodiments, an asset can be, but is not limited to a movie, a TV series episode, a documentary, a song, an application or a game, and can be made available as a stream or a file to download. Streamed assets can be linear (e.g. live TV channel) or on demand (e.g. VOD catalog). Access to download asset can be temporary (e.g. rental) or permanent (e.g. purchase).
In addition, at least one embodiment introduces service provider defined behaviors for the domain, such as a) player profiles that recommend a set of audio, video, streaming and download protocol parameters per subscriber device type, b) domain rules that limit the number of subscriber devices that can be registered to a domain, and c) asset rules that restrict the distribution of asset categories to approved DRM clients.
In at least some embodiments, playback of all past and current domain playback sessions can be resumed across multiple players registered within the domain.
In at least one embodiment, the gateway content distribution paths includes a broadcast legacy distribution network (e.g. cable or satellite), a transparent Internet Protocol based distribution network (e.g. Internet Protocol (IP) VOD over a cable or telco network), an opaque Internet Protocol based distribution network (e.g. Over-the-top Amazon “Cloudfront” or Akamai “Akamai HD Network”), a private home network, or a combination thereof.
The embodiments as described herein improve the user experience by dynamically feeding the application server with a fully integrated, synthetic and dynamic view of what assets can be played back and how they can be played back in the context of a given player connection within a domain.
The embodiments as described herein improve the authorization process by managing devices regardless of technology or DRM capabilities, managing assets with different distribution rules, and managing domains with different entitlement rights.
In at least some embodiments, a subscriber domain can include different types of client devices that are made using different technologies. For example, a client 110 can be an iPad, or Android tablet, and a client 111 can be a television with a network connection (“smart” TV), or a personal computer, for example a PC, or Mac. The subscriber devices can be secured with different Digital Rights Management (“DRM”) systems. For example, client 110 can be secured by a DRM A, and subscriber device 111 can be secured by a DRM B.
As shown in
In at least some embodiments, the application server sends a request to the DM server to get an adjusted domain catalog for the subscriber device. An adjusted domain catalog is described in further detail below. In at least some embodiments, a database (“DB”) coupled to the DM server, such as DB 102 stores information associated with the subscriber domains (e.g., data identifying the subscriber devices, playback positions, and other subscriber domain information). In at least some embodiments, a web application (not shown) coupled to the DM server and facing a service provider allows configuring, monitoring and analyzing the domain management activities, as described herein.
In at least some embodiments, DM 101 is a Maelstrom™ Domain Manager (MDM) server produced by Digital Keystone Inc., located in Mountain View, Calif.
In at least one embodiment, the DM server is designed to be scalable, and to integrate with the existing operator backend infrastructure. In at least some embodiments, the DM server includes one or more web services incorporating embodiments of methods as described herein to communicate with a OSS/BSS 103, a SMS 104, a CMS 105, a DRM License Servers 108 and 109, an application Server 107 and an ad-insertion Server 106.
The home gateway (e.g. gateway 114, and gateway 115) can receive media content from for example, a cable, satellite, terrestrial, or an IPTV legacy CDN, and can be coupled to a storage (not shown) to store a multimedia content. The network gateway (e.g. gateway 113) can directly access one or more content repositories (e.g. origin server). In at least some embodiments, a local IP network of the subscriber device is connected to a global IP network (e.g., Internet) through a router device (not shown).
In at least some embodiments, the subscriber devices 110 and 111 can include a player, which may be a software plug-in, an hardware decoder or the combination of both, for example, a Windows media player, a Flash media player, an iPod, a QuickTime media player, a RealTime media player, or any other video and/or audio player. The subscriber device can include an application program provided by the service provider or a browser to communicate with the application server 107.
In at least some embodiments, the application server in conjunction with the application program or the subscriber device browser, is configured to present a selection of media content to a user, for example, to find what to watch and to start playing the content. In at least some embodiments, the application server is further configured to receive playback control commands from a user, e.g., “play”, “fast forward”, “fast backward”, “jump”, “pause”, and the like, and to decide if that command needs to be sent to the player locally or needs to be sent to the gateway.
In at least some embodiments, the DM server is configured to provide one or more of the following: domain association, device type identification, content distribution path determination, device registration, catalog adjustment, DRM license authorization, and domain monitoring, as described in further detail below.
Operation 2102 involves authorizing media content within a subscriber domain of devices. In at least some embodiments, authorizing media content within a subscriber domain of devices involves, as described in further detail below receiving a request from a DRM license server and responding based on the state of the domain and the data carried in the request, as described in further detail below.
Operation 2103 involves monitoring media content within a subscriber domain of devices. In at least some embodiments, monitoring the media content consumption within a subscriber domain of devices involves recording all the requests from the DRM license servers and the playback state transition of the subscriber devices as reported by the gateways, as described in further detail below.
As shown in
In at least one embodiment, a discovery of the active content distribution paths to the gateways by the subscriber device is performed, as described herein.
In at least some embodiment, determining one or more content distribution paths to the associated gateways for the subscriber device also involves localizing the subscriber device by the gateways, identifying the presence of an edge-caching server interface, or a combination thereof.
Referring back to
A USER LOG IN 932 refers to requesting a user at subscriber device (client) 903 to enter her username and password, and requesting at 910 the creation of a new connection by the DM 901, using the received credentials. The DM 901 acknowledges and returns at 911 an executable code (e.g., a JavaScript file) that needs to be run on the subscriber device 903. In one embodiment, the user credentials are unique to a domain; in some other they are unique per user of the domain.
A DEVICE TYPE IDENTIFICATION 933 refers to executing the code providing at 911 on the subscriber device and returning the output result back to DM at 912. In one embodiment, the output result consists of an identifier unique to the characteristics of the platform, browser and plugin of the subscriber device.
CREATE CONNECTION 939 refers to creating in the DM 901 database a connection for the domain based on the identified subscriber device type value, a connection data is returned to the subscriber device by DM 901 at 913. In one embodiment, the connection data provided by the DM includes a list of all the domain gateway content distribution path identifiers (e.g. URLs and IP addresses).
A CONTENT DISTRIBUTION PATH DETERMINATION 934 refers to the client 903 querying all the domain gateway content distribution path identifiers at 914, 915, 917. Queries that manage to reach a gateway are echoed back to DM 901 at 920 and 921.
A CONNECTION INFO 940 refers to requesting the application server 902 for a connection information update at 924. Application server 902 sends a request for the connection information update to DM 901. DM 901 sends the connection information to application server 902 at 927. Application server 902 sends the connection information to client 903 at 938. The connection information includes an adjusted catalog that only includes the assets of the reachable domain gateways with a protocol and a format compatible with the identified subscriber type and a unique locator (e.g. URLs or IP addresses) that is compatible with the determined content distribution paths.
In one embodiment, the adjusted catalog is further filtered based on application parameters such as an asset category, a specific asset, a subscribed asset, or any combination thereof.
In one embodiment, the connection information response includes a hash value, which can be added in the following connection information requests to allow the DM 901, not to generate another adjusted catalog if no change has been detected. In one embodiment, the connection information changes if one or more of the following event has occurred: one of the participating domain gateways has added or removed titles; one of the participating domain gateways has changed its IP addresses; one of the domain gateways has dropped off the connection; and one of the domain gateways has joined the connection.
In at least some embodiments, upon initial play request, each subscriber device is requested to register with the DM.
In some implementations, the DM receives a status request at operation 2305 after it fails a license request authorization. The DM responds with a “Device Not Registered” error at operation 2306.
In some implementation, the DM receives a registration request at operation 2307 after it reported a registration error. The DM verifies at operation 2308 that the registration of a new device will not increase the domain size over the limit set by the domain rule.
If the maximum limit is already reached, the DM fails the registration request at operation 2310; otherwise the device is added to the subscriber domain at operation 2309.
In some implementation, the DM receives a status request at operation 2311 after it fails a device registration request. The DM responds with a “Maximum Player Exceeded” error at operation 2312.
In some implementation, the DM receives a device unregistration request at operation 2311 after it fails a device registration because of the number of players. The DM unregisters the selected device at operation 2314. In some implementation, the DM receives a second request for device registration at operation 2305 after the “Maximum Player Exceeded” error has been resolved.
PLAY ASSET 1005 refers to sending a request for an asset from a subscriber device CLIENT 1003 to a gateway GW 1004 at a transaction 1017, and receiving the asset from GW 1004 at a transaction 1018. At a transaction 1019, CLIENT 1003 has detected that the asset is encrypted and initiates a DRM license request to DM 1001, as instructed in the playlist/manifest. In this representation, the DRM License Server has been combined with the DM 1001. The DM 1001 determines that CLIENT 1003 is an unregistered player, and denies the authorization at a transaction 1020. However, DM 1001 adds the subscriber device 1003 to the domain with a “DISCOVERED” status at a transaction 1011. In one embodiment, depending on a type of a player, the custom license request error code may not be supported, and the application server is recommended to call DM to get a DM error code. As shown in
REGISTER CURRENT DEVICE 1006 refers to sending a request to register CLIENT 1003 to application server 1002 at a transaction 1024. The application server 1002 requests the registration by calling the DM 1001 at a transaction 1025. In this case, DM 1001 fails to register CLIENT 1003 and sends an error 2 “Number Player Exceeded” at a transaction 1026. Error 2 is forwarded to client 1003 by application server 1002 at a transaction 1027. In one embodiment, after receiving error 2, the application sends a request to unregister an older device.
UNREGISTER DEVICE 1007 refers to sending from a client 1003 a request to application server 1002 at a transaction 1028, application server 1002 calls DM 1001 at a transaction 1029 to get an inventory of all the registered players, which is provided by DM 1001 at operation 1030, and forwarded to CLIENT 1003 at operation 1031. Each device is uniquely identified by its DRM identity. In response, CLIENT 1003 requests to unregister one of the registered device at a transaction 1032, DM 1001 unregisters the selected device to application server 1002 at a transaction 1014, sends a confirmation to application server 1002 at a transaction 1033, which is forwarded to CLIENT 1003 at a transaction 1034.
REGISTER CURRENT DEVICE 1008 refers to sending from application server 1002 another request to register CLIENT 1003 to DM 1001 at a transaction 1036 in response to a request from a client 1003 at a transaction 1035. DM 1001 registers the current player device at a transaction 1015, and confirms successful registration to application server 1002 at a transaction 1037. Application server 1002 transmits this confirmation to CLIENT 1003 at a transaction 1038.
EDIT DEVICE INFO 1016 refers to sending a request from CLIENT 1003 to rename a registered device at a transaction 1039 to application server 1002. The application server 1002 calls the DM to for example rename the current device to “myiPad” at a transaction 1040. DM 1001 edits the information about the current player device at a transaction 1015, and confirms successful editing to application server 1002 at a transaction 1041. Application server 1002 transmits this confirmation to client 1003 at a transaction 1042.
The license server sends a request for a DRM license authorization to the DM. DRM license authorization is performed at a block 268 based at least on one of the domain association data, player registration data, player type identification data, content distribution path determination data, catalog adjustment data, and asset rules data. In at least one embodiment, the DM determines if all conditions regarding to the domain association data, player registration data, player type identification data, content distribution path determination data, catalog adjustment data, and asset rules data are met for the license authorization, as described in further detail below. If all conditions are met, a DRM license is approved at a block 274. The approved DRM license is sent to DRM license server 273. The DRM license server authorization ends at a block 275.
The DM enforces multi-dimensional content distribution rules. In at least some embodiments, at least three types of verification are made before releasing licenses to allow content consumption. In at least one embodiments, a transaction associated with a DRM license request is authorized if all of the following conditions are met: a player and a license request are properly authenticated; the player has been registered with a subscriber domain; the subscriber domain is entitled to access the requested asset at the time and location of the connection; and there is a matching asset rule that authorizes asset playback on that player at that location and at that time.
In at least one embodiment, the playback approval is dynamically updated when player approval, domain entitlement, or asset rules are created, updated or removed.
In at least some embodiments, upon content playback request, the DM verifies the integrity of input parameters for example to restrict access only to players that are properly authenticated; and to restrict access only to content that is properly authenticated.
In at least some embodiments, upon content playback request, the DM ensures that the player is properly registered, for example to restrict access only to subscriber devices that are registered in the same domain as the gateways.
In at least some embodiments, upon content playback request, the DM ensures that the domain is entitled to access the requested content at the time of playback. Entitlement verification, for example, allows an operator to define per-domain content entitlements, allows operator to limit entitlement to in-home consumption, restricts access to assets within certain asset classes in the domain (block non-subscribers), restrict access to devices in proximity if of the home gateways (block roaming players), and provides the application with authorization error code.
In at least some embodiments, upon content playback request, the DM ensures that the player is authorized to access the requested content at the time of playback. In at least some embodiments, content access per Digital Rights Management (DRM) for a given time window is defined by the operator according to a content agreement. Content contract verification, for example, allows the operator to define playback rights for an asset-class associated with a contract on a per-approved DRM basis; restricts playback to an approved DRM on a per asset-class basis; restricts playback to an up-to-date DRM on a per asset-class basis; restricts playback to devices in proximity on a per asset-class basis; and provides the application with authorization error/behavior code.
As shown in
a player certificate is used to retrieve the DRM type, DRM version and the Domain ID of the domain to which the player has been registered;
a connection ID is used to identify the Domain ID of the gateway;
an asset ID is used to query the content management tables to look-up for the corresponding asset class (for example VOD, Linear, or HBO), asset value (for example EIDR number or channel number) and content contract (i.e. for example view, rent, or own);
a proximity status is in the form True or False;
time is the server time when the license request is submitted.
In one embodiment, any failure to identify these parameters fails the license request.
Referring back to
Referring back to
Referring back to
Referring back to
Referring back to
Referring back to
In one embodiment, a contract name is a mandatory parameter that identifies the contract between the operator and the asset distributor. Asset rules are designed to enforce content distribution restrictions within the subscriber domain of such contracts. In one embodiment, a proximity status is an optional qualifier for the asset rule. When set to True in the asset rule record, it forces the asset only to be restricted to device(s) within the subscriber home. In one embodiment, time of the license request is within the asset rule record validity period. In one embodiment, any failure in asset rule verification fails the license request.
Referring back to
In at least some embodiments, the providing of the adjusted catalog enables any paused session to be resumed at any device of the subscriber domain. For example, a paused session between an original gateway and a subscriber device can be resumed within the domain according to four scenarios: with the original gateway and the current device, with an alternate gateway and the current device, with the original gateway and another device, and with an alternate gateway and another device.
DOMAIN DISCOVERY 1107, as the successive validation of domain association, device type identification, content path determination and adjusted catalog delivery is a prerequisite for CLIENT11103, as described above.
PLAY 1108 refers to sending a request for an asset of the adjusted catalog 1112 from CLIENT11103 to a gateway GW11104 at a transaction 1113, and receiving the asset from GW11104 at a transaction 1114. At a transaction 1115 CLIENT11103 has detected that the asset is encrypted and initiates a DRM license request to DM 1101, as instructed in the playlist/manifest. In this representation, the DRM License Server has been combined with the DM 1101. In response, DM returns the authorized license at a transaction 1116, which enables CLIENT11103 to start playback.
Upon playback state transition (e.g. from idle to play), CLIENT11103 calls all the gateways of the domain (e.g., GW11104 and GW21105) with the client's state and playback position (a transaction 1117 and a transaction 1119). GW11104 reports playback progress to DM 1101 at a transaction 1121. In response, DM updates the last position value of the applicable transaction record at block 1122. GW21105 does not respond to transaction 1119, as it is not involved in the connection at this time.
PAUSE 1109 refers to changing the state of CLIENT11103 from “play” to “pause”. CLIENT11103 calls all the gateways of the domain (e.g., GW11104 and GW21105) with the client's new state and playback position (a transaction 1120 and a transaction 1125). GW11104 replies to CLIENT11103 because client's state changed from play to pause at a transaction 1123. GW11104 reports state update and a paused position to DM 1101 at a transaction 1126, and keeps its content pipeline in place until the resources are directly requested by other connections. In response, DM 1101 updates the last position of the applicable transaction record at block 1127. GW21105 ignores the status update, as it is not currently providing the asset.
RESUME 1110 refers to GW11104 resuming delivering the asset at a transaction 1128. In one embodiment, GW11104 resumes delivering the asset to the same device from the same gateway according to a Table 1500, depicted in
FFW 5X 1111 refers to changing at CLIENT11103 to a playback forward speed five times faster than real time. CLIENT11103 sends a request including the speed, direction and the current playback position to GW 1104 at a transaction 1129. In response, GW11104 generates a trick mode stream at the requested speed from the same current playback position, and delivers the asset to client 11103 at a transaction 1130. System and methods for generating a trick mode stream at a gateway are described in U.S. patent application Ser. No. 12/772,064, Ser. No. 12/772,066 and Ser. No. 12/772,070, all entitled “METHOD & APPARATUS FOR A PROJECTED PVR EXPERIENCE”, which are incorporated herein by reference in its entirety.
END OF FILE/BUFFER 1131 refers to GW 11104 detecting that the end of a file is reached (recorded content) or the pause buffer is flushed and notifying DM 1101 at a transaction 1132. In response, DM 1101 updates the status of the transaction record complete at a transaction 1133.
DOMAIN DISCOVERY 1207, as the successive validation of domain association, device type identification, content path determination and adjusted catalog delivery is a prerequisite for CLIENT11203, as described above.
PLAY 1208 refers to sending a request for an asset of the adjusted catalog 1209 from CLIENT11203 to a gateway GW 1205 at a transaction 1210, and receiving the asset from GW 1205 at a transaction 1211. At a transaction 1212, CLIENT11203 has detected that the asset is encrypted and initiates a DRM license request to DM 1201, as instructed in the playlist/manifest. In this representation, the DRM License Server has been combined with the DM 1201. In response, DM returns the authorized license at a transaction 1213, which enables CLIENT11203 to start playback.
PAUSE 1214 refers to changing the state of the CLIENT11203 from “play” to “pause”. CLIENT11203 calls all the gateways of the domain (e.g., GW11205 and GW21206) with the client's new state and playback position (a transaction 1215 and a transaction 1218). GW11205 replies to CLIENT11203 at a transaction 1216. GW11205 reports a playback state update and a paused position to DM 1201 at a transaction 1217. In response, DM 1201 updates the last position of the applicable transaction record at block 1221. GW21206 does not respond, as it is not involved in the connection at this time.
DOMAIN DISCOVERY 1220, as the successive validation of domain association, device type identification, content path determination and adjusted catalog delivery is a prerequisite for CLIENT21204, after it logs in. The new adjusted catalog includes the resume position of the paused asset.
RESUME 1222 refers to CLIENT21204 requesting at a transition 1223 GW11205 to deliver the paused asset starting from the paused position. GW11205 resumes delivering the asset from the paused position to client 21204 at a transaction 1224. At a transaction 1225, CLIENT21204 has detected that the asset is encrypted and initiates a DRM license request to DM 1201, as instructed in the playlist/manifest. In this representation, the DRM License Server has been combined with the DM 1201. In response, DM returns the authorized license at a transaction 1226, which enables CLIENT21204 to start playback. In one embodiment, pause from CLIENT11203 and resume from CLIENT21204 is achieved when both subscriber devices are of different types, protected with different DRM system, or any combination hereof.
GW11205 resumes delivering the asset according to a Table 1600 depicted in
DOMAIN DISCOVERY 1307, as the successive validation of domain association, device type identification, content path determination and adjusted catalog delivery is a prerequisite for CLIENT11303, as described above.
PLAY 1308 refers to sending a request for an asset of the adjusted catalog 1309 from CLIENT11303 to a gateway GW 1305 at a transaction 1310, and receiving the asset from GW 1305 at a transaction 1311. At a transaction 1312, CLIENT11303 has detected that the asset is encrypted and initiates a DRM license request to DM 1301, as instructed in the playlist/manifest. In this representation, the DRM License Server has been combined with the DM 1301. In response, DM returns the authorized license at a transaction 1313, which enables CLIENT11303 to start playback.
PAUSE 1314 refers to changing the state of the client 11303 from “play” to “pause”. Client 11303 calls all the gateways of the domain (e.g., GW11305 and GW21306) with the client's new state and playback position (a transaction 1315 and a transaction 1319). GW11305 replies to client 11303 at a transaction 1316. GW11305 reports a state update and a paused position to DM 1301 at a transaction 1317. In response, DM 1301 updates the last position of the applicable transaction record at block 1321. GW21306 does not respond, as it is not involved in the connection at this time.
DOMAIN DISCOVERY 1322, as the successive validation of domain association, device type identification, content path determination and adjusted catalog delivery is a prerequisite for CLIENT11303, after it logs in again. The new adjusted catalog includes the resume position of the paused asset.
RESUME 1323 refers to CLIENT11303 requesting at a transaction 1324 GW21306 to deliver the previously paused asset starting from the paused position. GW21306 resumes delivering the asset from the paused position to CLIENT11303 at a transaction 1325. At a transaction 1312, CLIENT11303 has detected that the asset is encrypted and initiates a DRM license request to DM 1301, as instructed in the playlist/manifest. In this representation, the DRM License Server has been combined with the DM 1301. In response, DM returns the authorized license at a transaction 1313, which enables CLIENT11303 to start playback.
In one embodiment, GW21306 resumes delivering the asset according to a Table 1700 depicted in
DOMAIN DISCOVERY 1407, as the successive validation of domain association, device type identification, content path determination and adjusted catalog delivery is a prerequisite for CLIENT11403, as described above.
PLAY 1408 refers to sending a request for an asset of the adjusted catalog from CLIENT11403 to a gateway GW11405 at a transaction 1409, and receiving the asset from GW11405 at a transaction 1410. At a transaction 1411, CLIENT11403 has detected that the asset is encrypted and initiates a DRM license request to DM 1401, as instructed in the playlist/manifest. In this representation, the DRM License Server has been combined with the DM 1401. In response, DM returns the authorized license at a transaction 1412, which enables CLIENT11403 to start playback.
PAUSE 1413 refers to changing the state of CLIENT11403 from “play” to “pause”. CLIENT11403 calls all the gateways of the domain (e.g., GW11405 and GW21406) with the client's new state and playback position (a transaction 1414 and a transaction 1419). GW11405 replies to client 11403 at a transaction 1417. GW11405 reports a state update and a paused position to DM 1401 at a transaction 1417. In response, DM 1401 updates the last position of the applicable transaction record at a block 1418. GW21406 does not respond, as it is not involved in the connection at this time.
PLAY 1421 refers to sending a request for another asset of the adjusted catalog from CLIENT11403 to the same gateway GW11405 at a transaction 1422, and receiving the asset from GW11405 at a transaction 1423. At a transaction 1424, CLIENT11403 has detected that the asset is encrypted and initiates a DRM license request to DM 1401, as instructed in the playlist/manifest. In this representation, the DRM License Server has been combined with the DM 1401. In response, DM returns the authorized license at a transaction 1425, which enables CLIENT11403 to start another playback session. In one implementation, GW11405 has limited resources and had to tear down the pipelines of the paused session to support the new one.
DOMAIN DISCOVERY 1426, as the successive validation of domain association, device type identification, content path determination and adjusted catalog delivery is a prerequisite for CLIENT21404, after it logs in. The new adjusted catalog includes the resume position of the paused asset.
RESUME 1427 refers to CLIENT21404 trying to resume playing the initially selected asset from the original gateway GW11405 (transactions 1435 and 1429), and receiving (block 1431) a response from the GW11405 that it is busy (transactions 1428 and 1430). In some embodiment, CLIENT21404 sends a request for the same asset to GW21406 at a transaction 1432. GW21406 resumes delivering the initially selected asset from the paused position to CLIENT21204 at a transaction 1433. At a transaction 1435, CLIENT21404 has detected that the asset is encrypted and initiates a DRM license request to DM 1401, as instructed in the playlist/manifest. In this representation, the DRM License Server has been combined with the DM 1401. In response, DM returns the authorized license at a transaction 1434, which enables CLIENT21404 to start a playback session.
Transaction record 1801 includes a transaction identifier (idTransaction (P)), a connection identifier (idConnection), a subscriber identifier (idSubscriber), an asset identifier (idAsset), a gateway URL identifier (idGatewayUrl), a profile identifier (idProfile), and one or more parameters. In some embodiments, the parameters include an optional dcTitle value to identify user content, a Qos parameter (bitrateQoS) to represent bitrate consumption, a playback position when the transaction is created (startPosition), a playback position when the transaction is updated (endPosition), a time when the transaction record is created (createTime), a time when the transaction record is last updated (updateTime), and a transaction status. In one embodiment, the bitrateQos parameter represents the bitrate usage distribution over the period of the transaction (endPosition-startPosition).
In at least one embodiment, a domain playback session can be defined as a series of transactions for the same asset within a same domain. That is, when a session is paused and resumed on a different device, or on a same device but in the context of a different connection, successive transactions can be aggregated as one session for the purpose of consumption reporting.
At operation 2504, a request for one of the advertised asset is received with a specific profile, position and speed. The gateway provides the asset in the format request at operation 2505. In some implementation, the asset in the requested format is pre-packaged and ready to be delivered, in some other the operations of packaging are happening upon request.
At operation 2506, a notification of a playback status is received from one of the active subscriber devices. In one implementation, the playback status is received when the subscriber device is changing state (e.g., from “play” to “pause”, “pause” to “play”, “play” to “fast forward”, “fast forward” to “play”, “play” to “stop”, “stop” to “play”, and other status change), in some other a playback status is sent periodically by the subscriber device. The gateway responds to the caller at operation 2507, and reports the connection activity to the DM.
In response, the subscriber device receives at operation 2603 a list of possible content distribution path identifiers associated to the subscriber domain and starts querying all the identifiers. Successful queries are reported by the domain gateways to the DM to determine which content distribution paths are operational. After a first gateway responded to the identifier queries, a request for navigation data is sent to an application server at operation 2604. In some embodiment the navigation data includes an adjusted catalog provided by the DM.
Upon reception of the adjusted catalog and other navigation data, a complete navigation experience is generated for the purpose of content selection at operation 2605. Upon selection, a request for the asset to the source gateway and then a request to the DRM license server are sent at operation 2606. After receiving both the asset and matching DRM license, the subscriber device start rendering at operation 2607.
At operation 2608, a playback status update is sent to the sourcing gateway. In some implementation, playback updates are sent after detection of a change of playback state by the subscriber device, in some other the updates are sent periodically.
Processing unit 2901 may include a personal computer (PC), such as a Macintosh® (from Apple Inc. of Cupertino, Calif.), Windows®-based PC (from Microsoft Corporation of Redmond, Wash.), or one of a wide variety of hardware platforms that run the UNIX operating system or other operating systems. In at least some embodiments, processing unit 2901 includes a general purpose or specific purpose data processing system based on Intel, AMD, Motorola, IBM, Sun Microsystems, IBM processor families, or any other processor families. As shown in
Memory 2903 can be dynamic random access memory (DRAM) and can also include static random access memory (SRAM). A bus 2923 couples processing unit 2901 to the memory 2903 and also to non-volatile storage 2909 and to display controller 2905 (if a display is used) and to the input/output (I/O) controller(s) 2911. Display controller 2905 controls in the conventional manner a display on a display device 2907 which can be a cathode ray tube (CRT), liquid crystal display (LCD), or any other display device. The input/output devices 2917 can include a keyboard, disk drives, printers, a scanner, a camera, and other input and output devices, including a mouse or other pointing device. The I/O controller 2911 is coupled to one or more audio input devices 2913, for example, one or more microphones.
The display controller 2905 and the I/O controller 2911 can be implemented with conventional well known technology. An audio output 2915, for example, one or more speakers may be coupled to an I/O controller 2911. The non-volatile storage 2909 is often a magnetic hard disk, an optical disk, or another form of storage for large amounts of data. Some of this data is often written, by a direct memory access process, into memory 2903 during execution of software in the data processing system 2900 to perform methods described herein.
One of skill in the art will immediately recognize that the terms “computer-readable medium” and “machine-readable medium” include any type of storage device that is accessible by the processing unit 2901. A data processing system 2900 can interface to external systems through a modem or network interface 2921. It will be appreciated that the modem or network interface 2921 can be considered to be part of the data processing system 2900. This interface 2921 can be an analog modem, ISDN modem, cable modem, token ring interface, satellite transmission interface, or other interfaces for coupling a data processing system to other data processing systems.
It will be appreciated that data processing system 2900 is one example of many possible data processing systems which have different architectures. For example, personal computers based on an Intel microprocessor often have multiple buses, one of which can be an input/output (I/O) bus for the peripherals and one that directly connects the processing unit 2901 and the memory 2903 (often referred to as a memory bus). The buses are connected together through bridge components that perform any necessary translation due to differing bus protocols.
Network computers are another type of data processing system that can be used with the embodiments as described herein. Network computers do not usually include a hard disk or other mass storage, and the executable programs are loaded from a network connection into the memory 2903 for execution by the processing unit 2901. A typical data processing system will usually include at least a processor, memory, and a bus coupling the memory to the processor.
It will also be appreciated that the data processing system 2900 can be controlled by operating system software which includes a file management system, such as a disk operating system, which is part of the operating system software. Operating system software can be the family of operating systems known as Macintosh® Operating System (Mac OS®) or Mac OS X® from Apple Inc. of Cupertino, Calif., or the family of operating systems known as Windows® from Microsoft Corporation of Redmond, Wash., and their associated file management systems. The file management system is typically stored in the non-volatile storage 2909 and causes the processing unit 2901 to execute the various acts required by the operating system to input and output data and to store data in memory, including storing files on the non-volatile storage 2909.
In various embodiments, hardwired circuitry may be used in combination with software instructions to implement methods described herein. A machine readable medium can be used to store software and data which when executed by a data processing system causes the system to perform various methods described herein. This executable software and data may be stored in various places including for example ROM, volatile RAM, non-volatile memory, and/or cache. Portions of this software and/or data may be stored in any one of these storage devices.
Thus, a machine readable medium includes any mechanism that provides (i.e., stores and/or transmits) information in a form accessible by a machine (e.g., a computer, network device, or any device with a set of one or more processors, etc.). For example, a machine readable medium includes recordable/non-recordable media (e.g., read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; and the like.
The methods as described herein can be implemented using dedicated hardware (e.g., using Field Programmable Gate Arrays, or Application Specific Integrated Circuit) or shared circuitry (e.g., microprocessors or microcontrollers under control of program instructions stored in a machine readable medium. The methods as described herein can also be implemented as computer instructions for execution on a data processing system, such as system 2900 of
In the foregoing specification, embodiments as described herein have been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope of the embodiments as described herein. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.
This application claims the benefit of U.S. Provisional Application No. 61/565,876, filed on Dec. 1, 2011, which is incorporated by reference herein in its entirety.
Number | Date | Country | |
---|---|---|---|
61565876 | Dec 2011 | US |