Protecting content with built-in DRM

In-app purchase supports using built-in DRM to protect the purchase items. After a successful purchase, the user is granted access to the DRM-protected content stored in the application.

Nokia Store provides the DRM and the associated license management service compatible with Nokia devices. For Series 40 devices, the DRM support is compliant with OMA DRM 2.0.

The purchasing process is slightly different depending on whether or not built-in DRM is used. In case of DRM, the protected content is stored in the application downloaded from Nokia Store, and purchasing it means that it is simply unlocked in the application. This means that no content download occurs when the user purchases (or restores) the content from Nokia Store. It also means that if you (the publisher) create new DRM-protected content after the application has already been released to and downloaded by users, you need to provide the new content via an application update.

In case of DRM-protected content, Nokia Store is also able to check during the purchasing process if the user has purchased the product earlier and is still entitled to restore it without any cost. If this is the case, Nokia Store automatically switches from a purchasing process to a restoration process.

In practice, you can use built-in DRM for any "physical" purchasable resources (such as files) that can be protected using OMA DRM 2.0. In case of services, one possible design is to use some gating asset that provides access to the service, and store this gating asset in a text file, which can then be protected using OMA DRM 2.0.

To protect content with built-in DRM:

  1. Log in to Nokia Publish and retrieve the unique ID of each purchase item that is to be DRM-protected.

  2. Store the resource files for the purchase items in the <project_root>\<resource_folder>\drm\data folder of your application project. Store the resource files for each purchase item in their own subfolder named resourceid_x where x is the unique ID of the corresponding purchase item. This ensures maximum content security. For example, in an Eclipse project, store the files in:

    <project_root>\res\drm\data\resourceid_x

    Note: The JAR file for the MIDlet must have the \drm\data folder inside the \res folder, the latter of which must be located in the root of the JAR file, so that the full folder structure is <JAR_root>\res\drm\data. To ensure that the JAR file is built correctly in Eclipse, create a \res\drm\data folder in the project root folder. In NetBeans, create a \drm\data folder in the project root folder; do not create a \res folder, since in NetBeans the project root folder is also the resources root folder by default.

    Note: You can use the SDK emulator to create the correct DRM subfolders automatically. For more information, see the SDK documentation.

    Note: Store resource files that are not to be DRM-protected to other folders in the application project.

  3. Review your application’s code with a focus on the areas where access to the DRM-protected files is managed. Access to protected resource files must be implemented with the IAPClientPaymentManager.getDRMResourceAsStream method. Access to unprotected resource files can be implemented with the IAPClientPaymentManager.getDRMResourceAsStream method or any other existing file access API, such as the FileConnection API or the Class.getResourceAsStream method. For code examples, see sections Purchasing a product and Restoring a product.