Binding Viewer Devices to Entitlements

To protect your assets and ensure that you realize all possible revenue, with Rights Locker in conjunction with the Device Registration API, you can programmatically bind the entitlements your viewers purchase to the viewers' devices. This binding can prevent your customers from accessing content that they have not purchased.

Relationship of Device Limits and Device Binding

There are several different limits associated with devices and device binding that interact with each other.

  • With the Device Registration API you can build a portal for your users or customer support to manage registered devices. An essential parameter is the device_limit: the upper bound on the number of devices each of your viewers can register. This setting is at the provider level and prevents multiple viewers from sharing the same account.
  • Rights Locker gives you the ability to "bind", or associate, the viewer's devices to your content via entitlements. The essential parameter is the allowable number of devices that can be bound: num_devices_to_bind. This setting is at the viewer level. For example, after a viewer purchases a video, once a viewer starts watching a purchased video on a particular device, the video is restricted to that specific device.

You can bind as many devices as is limited by the device registration device_limit.

These limits are shown graphically below.

  • On the left ("A") is the normal relationship: number of devices to bind is a subset of the overall device limit.
  • The right ("B") shows a case that is possible but that you should make sure to prevent.

    When you create a device-bound entitlement, Ooyala does not check the number of bindable devices against the upper limit of devices per provider. This is both for speed of performance and for separation of concern. Most logically, a device-bound entitlement is part of your checkout or purchasing process on your site. Ooyala has made the creation of entitlements simple to fit in with your checkout, but it is up to you to ensure that "Case B" shown above does not occur, because at playback time, in "Case B", a viewer is denied authorization to access the asset.

Thus, in the design of your device registration portals and your checkout, you need to keep track of the counts of viewers' device such that "Case B" is avoided.

Creating a Device-bound Entitlement

When you create an entitlement, include num_devices_to_bind in the body of the request, for either assets or labels as described in Rights Locker API Reference and highlighted below.

 “assets” : 	[
     { “content_id” : “an_embed_code”,
       “publishing_rule_id” : “publishing_rule_id”,
	   “external_product_id” : “your_product_id”,
       “start_time” : YYYYMMDD,
       “end_time” : YYYYMMDD,
       "num_devices_to_bind" = upper limit number of devices to bind to content 
     { “content_id” : “another_embed_code”,
 “labels” :	[
     { “content_id” : “a_label_id”,
       “publishing_rule_id” : “publishing_rule”,
	   “external_product_id” : “your_product_id”,
       “start_time” : YYYYMMDD,
       “end_time” : YYYYMMDD
       "num_devices_to_bind" = upper limit number of devices to bind to content
     { “content_id” : “another_label_id”,
Note: Ooyala recommends that you create device-bound entitlements only for assets, not for labels. A label-based device-bound entitlement means that the viewer must access all assets under the label only from the same device, which is a bad user experience.

Modifying an Entitlement's num_devices_to_bind: Create New Entitlement

You cannot change the value of an existing entitlement's num_devices_to_bind.

Instead, delete the outdated entitlement, and create a new entitlement with the desired value of num_devices_to_bind.

Basic Workflow with Device Registration and Binding

The following use case illustrates a basic pattern in device binding. (As detailed in the Device Registration API, actual device registration is automatic. You do not need to make any explicit request.)
Note: Not included in this workflow is any necessary interaction with the device registration portal or with your checkout process.
  1. A viewer purchases a single-device movie.
  2. You create an entitlement for that viewer, including num_devices_to_bind = 1.
  3. The viewer starts watching the movie on an iPhone.
  4. The player application makes a request to Ooyala services for authorization, using the Player Authorization API for Player V3.
  5. Ooyala services determine that the single-use entitlement has not yet been used and registers the iPhone for that entitlement.
  6. The viewer tries to watch the same movie on a laptop.
  7. The player application makes the authorization request, using the Player Authorization API for Player V3.
  8. Ooyala services determine that the single-use entitlement has already been used and playback is not authorized.

Some Behavior to Consider

Discussed below are some basic behaviors of device binding and some possible "corner cases" to take into consideration, including programmatic action (if any) you need to take.
  • Context: The viewer has two entitlements:
    1. Asset-based entitlement restricting access to a single device
    2. Label-based entitlement (that includes the asset in (1) using the viewer-level device restriction
    The viewer has already registered the device for (2).

    Behavior or Result: When the viewer tries to watch the asset on the same device, playback is authorized but Ooyala does not re-register the device for entitlement (1).

  • Context: A viewer has two entitlements:
    1. Asset-based entitlement that restricts access to a single device for this asset
    2. Label-based entitlement (that includes the asset in (1) that uses the viewer-level device restriction

    The viewer is using a new, different device that has not been bound to either entitlement.

    Behavior or Result: Ooyala binds the new device randomly to one and only one of the entitlements.

  • Context: Single-device entitlements created based on a label

    Behavior or Result: Because this restriction will require the viewer to use the same device to watch all the assets in that label, this usage is not recommended because it is a bad user experience.

  • Context: Purchasing the same movie for two different single-device entitlements

    A viewer buys a single-device movie and watches it on his T-box. He also wants to watch this on his mobile phone, so he buys the movie a second time.

    Your action: The first purchase results in num_devices_to_bind = 1. With the second purchase, you need to increase the viewer's existing entitlement. You first need to delete the existing entitlement and then create a new one with num_devices_to_bind = 2. This means that you must keep track of how many devices a viewer can register for an entitlement., as discussed in the introduction.