• JSRs by Platform
• JSRs by Technology
• JSRs by Stage
• JSRs by Committee
• List of All JSRs



Register for Site

Use of JCP site is subject to the JCP Terms of Use and the Oracle Privacy Policy


• About JCP
  • Program Overview
  • JCP Process Document
  • Calendar
  • JCP Members
  • Executive Committee
  • Elections
• Get Involved
  • Overview
  • Becoming a JCP Member
  • Java in Education
• Community Resources
  • Overview
  • Tutorials
  • JCP Podcasts
  • Spec Lead Guide
  • TCK Tool & Info
  • License Reference
• Community News
  • News
  • Programs & Awards
  • Press Releases
  • Success Stories
• FAQ
• Contact Us

Updates to the Original JSR

The following updates were made to the original request:

2009.07.06: The Maintenance Lead changed to Sun Microsystems.

Specification Lead: Jean-Yves Bitterlich

E-Mail Address: jean-yves.bitterlich@sun.com

Telephone Number: +49 89 46008 1097

Fax Number: -

Original Java Specification Request (JSR)

Identification | Request | Contributions

Section 1. Identification

Submitting Member: Siemens

Name of Contact Person: Jean-Yves Bitterlich

E-Mail Address: jean-yves.bitterlich@siemens.com

Telephone Number: +49 89 722 58563

Fax Number: +49 89 722 35087

Specification Lead: Jean-Yves Bitterlich

E-Mail Address: jean-yves.bitterlich@benq.com

Telephone Number: +49 89 722 58563

Fax Number: +49 89 722 35087

Initial Expert Group Membership:

Supporting this JSR:

Motorola
Siemens
Nokia Corporation

Section 2: Request

2.1 Please describe the proposed Specification:

The purpose of this JSR is to define the following:
- A generic optional API to initiate payment transactions and
- In addition the syntax for the description of the associated provisioning data, enabling API implementers to support different payment instruments.

Both will allow 3rd party developers to build applications with control of features and services that are chargeable. The JSR API may include methods for
- Requesting payment transaction
- Requesting feature and service price management
- Payment service availability
The provisioning data definitions take care that service providers and payment service providers can select a suitable set of payment instruments provisioned for applications during the application deployment time. Primarily payment instruments addressed will be
- Operator charging
- Stored value accounts
- 3rd party payment service providers

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

The target Java platform is the J2ME. This optional package will run on both configurations CDC and CLDC.

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

The only way to gain revenue for a J2ME application developer until now was either to sell the application or be paid per download. This JSR will provide a solution to allow J2ME application developers to gain revenue at a finer grained basis controlled directly from within J2ME applications, i.e. pay per level, and pay per feature... By having a standard payment API, 3rd party developers? productivity will be increased.

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

Neither the CLDC and CDC nor any available profile or API specifications do not cover payment. In particular the focus of JSR-182 (Payment API for the Java platform) is different: while the proposed JSR will define an API between a (mobile) application and a payment facility, JSR-182 concentrates on handling of payment interactions with web-based services. Therefore, JSR-182 could be used to implement one of the payment methods as supported by this proposal (i.e. JSR-182 is one possible payment instrument).
The potential and particular interaction between this JSR and JSR-190 will be analysed and clarified by the Expert Group during the specification process and after JSR190 will be published.

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

This JSR focuses on the definition of a generic API that covers any payment methods (e.g. premium priced SMS or others), which themselves are based on different existing communication bearers (e.g. http, GSM).

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

Package: javax.microedition.payment

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

No

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

Probably no.

2.9 Are there any internationalization or localization issues?

No (interface does not deal with text).

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

No

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

Community Draft: E-Q2/2004
Final Release: E-Q3/2004

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

It is anticipated that a combination of email discussion, feedback on regular drafts, conference calls and face-to-face meetings will work well.

2.13 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.

Due to the optional package character of this request, RI and TCK will be delivered as standalone products.

2.14 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).

N/A

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

Early information on license terms as defined in the JCP process: Siemens will license to all interested parties. TCK and RI will be available separately for license, independent implementations will be allowed.
TCK will be licensed free of charge for qualified not-for-profit and qualified individuals.
Commercial terms
- For TCK we will charge a single one time fee and annual maintenance fee
- For RI we will charge an initial access fee and per-unit royalty
Due to the running negotiations about a general solution of the licensing terms question, this proposal is subject of changes.

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.

- JSR 30: Connected, Limited Device Configuration Specification (CLDC)
- JSR 139: Connected, Limited Device Configuration Specification (CLDC 1.1)
- JSR 118: Mobile Information Device Profile 2.0 (MIDP)
- JSR 37: Mobile Information Device Profile 1.0 (MIDP)
- JSR 36: Connected Device Configuration (CDC)

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

Due to the optional package character of the request, considerable cross references towards configurations and profiles the package is based on are expected.