Find JSRs
Submit this Search

Ad Banner

JSRs: Java Specification Requests
JSR 300: DRM API for JavaTM ME

Updates to the Java Specification Request (JSR)

The following information has been updated from the original JSR:

2008.06.19: Spec Lead: Dnyanesh R Pathak

email id:

Telephone Number: +91 80 6615 5000

Fax Number: +91 80 6615 5100

Public Review: June 2008
Final specification: Q3/2008.

If you would like to be added to the observer alias for this JSR and receive e-mail updates on the progress of the JSR, please send e-mail to the Spec Lead with "Add to observer alias" in the subject line.

Original Java Specification Request (JSR)

Identification | Request | Contributions | Additional Information

Section 1. Identification

Submitting Member: LG Electronics Inc.

Name of Contact Person: Yong Moo Kim

E-Mail Address:

Telephone Number: +82 31 450 1915

Fax Number: +82 31 450 4049

Specification Lead: Dnyanesh Pathak

E-Mail Address:

Telephone Number: +91 80 5515 5000

Fax Number: +91 80 5515 5100

Note that this information has been updated from the original JSR.

Initial Expert Group Membership:

Sun Microsystems Inc.

Supporting this JSR:

Sun Microsystems Inc.

Section 2: Request

2.1 Please describe the proposed Specification:

JavaTM ME platform enables users to download and use the digital content on the mobile handsets.
With increase in the capabilities, more and more digital content will be downloaded, used on the mobile handsets. The content thus downloaded/accessed using the Java platform needs to be handled according to the digital rights associated with it, if any. The Java platform therefore needs to provide a standardized approach for handling the DRM content.
The proposed JSR is an optional package intended for handling DRM protected digital content (for example OMA DRM2.0 and other proprietary DRM standards) being accessed by the Java applications. With help of this JSR, the application developers/providers will be able to avail a standardized approach for handling of the DRM protected content.
Basically, this JSR enables Java applications to interact with the DRM agent for

    (1) Identifying that the content is DRM protected content
    (2) Getting the information on the rights associated with content ? for enabling user to make decision on rights download
    (3) Getting the DRM protected content in secure manner for rendering

The proposed JSR will bring out generic APIs for enabling the Java ME applications to access the DRM Content, abstracting out how the DRM content is handled internally by the underlying DRM Agent(s)

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

The target is JavaTM platform for embedded devices (JavaTM ME).

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

The minimum configuration is the J2ME Connected, Limited Device Configuration v1.1. This Optional Package should be usable with any J2ME Profile based on that Configuration as well as Profiles based on the Connected Device Configuration

2.4 Should this JSR be voted on by both Executive Committees?


2.5 What need of the Java community will be addressed by the proposed specification?

Strength of JavaTM platform is mainly to support application portability and thus OTA download ability of JavaTM applications and digital content. The content being downloaded/ accessed needs to be protected against piracy and for revenue generation based on its usage by the end user. The proposed JSR will provide a standardized support for digital content protection and management of the rights by providing APIs to interact with the underlying DRM agent(s). The developers can use this JSR for interacting with the DRM agents for developing applications that handle the DRM protected content.

2.6 Why isn't this need met by existing specifications?

The existing J2ME specifications do not provide specific support for OMA DRM or other DRM specifications.

2.7 Please give a short description of the underlying technology or technologies:

DRM Description: The "Digital Rights Management" (DRM) enables the distribution and consumption of digital content in a controlled manner. The content is distributed and consumed on authenticated Devices per the usage rights expressed by the content owners. One of such prominent DRM specifications is OMA DRM2.0. OMA DRM addresses various technical aspects of this system by providing appropriate specifications for content formats, protocols, and a rights expression language.

2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)


2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?


2.10 Are there any security issues that cannot be addressed by the current security model?


2.11 Are there any internationalization or localization issues?


2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?


2.13 Please describe the anticipated schedule for the development of this specification.

The anticipated schedule for the JSR is as follows:
Early Draft Review: Q3/2006
Public Review: Q2/2007
Final specification: Q4/2007

Note that this information has been updated from the original JSR.

2.14 Please describe the anticipated working model for the Expert Group working on developing this specification.

The Expert Group communication will be mainly via emails and teleconferences. The face-to-face meetings will be organized at regular intervals as required and for the major milestones for critical decisions.

2.15 It is important to the success of the community and each JSR that the work of the Expert Group be handled in a manner which provides the community and the public with insight into the work the Expert Group is doing, and the decisions that the Expert Group has made. The Executive Committees would like to ensure Spec Leads understand the value of this transparency and ask that each JSR have an operating plan in place for how their JSR will address the involvement of the community and the public. Please provide your plan here, and refer to the Spec Lead Guide for a more detailed description and a set of example questions you may wish to answer in your plan.

The details of the progress of the JSR will be informed to the community and the public by updating the JSR Community page regularly as the JSR progresses. The latest drafts will be published for community and public review using the JSR Community page.
Observer alias will be used to keep all the community members informed about the progress, decisions and updates periodically.

2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

Standalone RI and TCK will be produced as a part of this JSR.

2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).


2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.

These terms only represent the initial commercial terms planned to be used at this time and remain subject to the execution of final legal agreements covering the subject matter hereof to be determined by LG Electronics at its sole discretion. Independent implementations will be allowed. RI and TCK will be licensed separately to all interested parties.
For the TCK we will charge a single one-time fee of max US $50,000 and an annual maintenance fee, max US $20,000 for a term of four years. The TCK will include both the binary environment and the source code for the test suite. The maintenance fee covers limited basic support, first level TCK appeals process, bug fixes when available and updates, which are due to changes in the Specification. Major new releases (esp. from new follower JSR) might be subject to an additional single one-time fee.

For the RI we will charge a one-time access fee, and an annual maintenance fee.

Section 3: Contributions

3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

The OMA DRM2.0 standards are referred to, to bring up the basic idea for this JSR. DRM Sub-Working Group in Open Mobile Alliance (OMA) Browser and Content Working Group (BAC) (

3.2 Explanation of how these items might be used as a starting point for the work.

As mentioned above, the OMA Standards for DRM are used to bring up the concept of this JSR. This standard will be referred to for designing this JSR.

Section 4: Additional Information (Optional)

4.1 This section contains any additional information that the submitting Member wishes to include in the JSR.