With the present possibility of downloading new J2ME applications over the air, the transformation of the mobile phone into something extraordinary is well underway. Today’s applications are primarily local applications: they are downloaded onto the device and then run without requiring network connections. They range from numerous personal productivity tools to games. More sophisticated applications are on their way; things like location-based applications or audio and video streaming, which require connection to the internet and content sources.

The mobile phone’s complete transformation into a versatile smartphone depends crucially on one thing: the business model. The business model affects both customer uptake and the distribution of payment among the various players (particularly, developers and content providers) that bring the product to the customer.

The Significance of Billling Models
At the moment, the most common billing models for J2ME applications are based on payment per download or by subscription. This model is rapidly becoming a hindrance to mobile development.

Upon hearing of a new product, interested customers want to do one thing: try it out. They don’t want to sign forms, commit to memberships, or jump through hoops. For instance, the success of the short message service (SMS) is, in part, due to its billing model. Rather than charge users according to a network data packet rate, users were charged 10 cents per outbound message. Its simplicity is admirable: 10 cents each time, day or night.

This notion of pay-per-use for J2ME applications demonstrates the advantages of value-based billing models over per download or subscription models for each segment of the value chain.

For consumers, it eliminates high upfront costs, such as subscriptions, with an unknown value. The consumer has no reason not to try the application.

For the mobile operator, value-based billing is easy to administer and offers greater billing flexibility?operators are not tied to a single billing system. Stock quotes, for example, could be billed in any of the following ways: (i) per use of the service, (ii) per quote, (iii) or service subscription + per use. Because of the flexibility, new services involving much more sophisticated applications can be quickly implemented. Operators also benefit from personalized data on customer habits.

Content providers and developers get immediate feedback on usage statistics and can react quickly to market demands to deliver premium services, applications, and even application upgrades. In the case of games, popular games that are pay-per-play will have the opportunity to earn several times their “per download” value, providing incentive for developers to create other, diverse applications.

Implementing Value-based Billing
Mobile operators do not typically allow external parties direct access to their billing systems because they usually contain sensitive customer and financial data. However, in order to facilitate value-based billing, mobile operators need to provide an interface for applications to record those billing events. This interface is usually proprietary in nature. A typical scenario is illustrated in the following diagram:

	Figure 1: Here’s a generic model of a billing event recording interface.

As shown in the diagram, each mobile operator has its own proprietary interface to access its billing system. Consequently, the same J2ME application needs be modified in order to adapt to different billing interfaces, forcing publishers to write one version of an application for each billing interface (and hence for each operator). This often means a large amount of resources are spent writing, maintaining, testing, and certifying billing routines rather than applications. Such efforts defeat Java’s promise of “Write once, run anywhere”.

On the other hand, if mobile operators want to facilitate value-based billing, they can only sell applications that can interface with their systems. This greatly reduces the size of the available pool of applications.

What both parties require is a common way to submit and access all the event information. Operators need a way to collect billing event data from a variety of applications, while publishers need a single interface to submit billing events that is independent of any one operator. In short, both parties require an interoperable way to access billing events, i.e., open event-tracking capabilities.

To make value-based billing models viable and flexible, information about the number of units of consumption (or number of plays) is required. Tira Wireless has been leading the specifications team to develop JSR 190 to do just that.

Optimized Value-based Billing: JSR 190
JSR 190 is an extension to the existing J2ME specifications that allows standardized tracking of application events and the submission of these events to a tracking server via a standard protocol (such as HTTP). Effectively, the Java code is instructed to record events (such as number of plays), and report it when the user has network connectivity again. The user’s privacy is protected by different methodologies, for example with the use of application serial numbers.

JSR 190 has several benefits. As a standard, it streamlines the development process because developers have a standardized tracking methodology for use in their programs. This optimizes memory usage and the process of event tracking itself since all applications contain the same billing language. Until now, a standard has not existed, so this is an important move forward.

For service providers, JSR 190 allows operators to source applications from a variety of publishers or developers; these applications track usage and are able to communicate that usage to a billing system without costly custom integration.

For mobile operators, it allows the ability to differentiate casual and heavy users and bill them accordingly, and provides a versatile billing model to be in place for the more sophisticated applications that are being developed. The ability to monitor and track data usage gives operators the opportunity to adjust their billing systems, respond quickly to market demands, and remain competitive.

The JSR 190 Event Tracking API
The JSR 190 Event Tracking API contains two major sets of interfaces: the first is the Event Tracking API for application developers, and the second is the protocol between the mobile devices and the mobile operator’s backend infrastructure, which connects to the operator’s billing system. The high-level architecture is shown in the following diagram:

The Event Tracking API allows applications to access multiple operators without having to understand the underlying interface. It also allows operators to expose a common event-tracking interface without exposing a subset of its own billing interface or creating its own proprietary interface.

It is important to understand that Event Tracking API is designed to expose event-tracking capabilities, not supplement them. Thus, application writers should not expect that using Event Tracking APIs would suddenly transform a billing system incapable of handling event-based billing into a fully featured billing system. Event Tracking APIs addresses only the event-tracking interface. How the underlying systems handle the event is out of the scope of the specification.

Background on MIDlet Programming
For those readers who are not familiar with MIDlet programming, this section provides some background information. The experts can safely proceed to the following section.

A MIDlet is an application written for the Mobile Information Device Profile (MIDP) for J2ME. The Mobile Information Device Profile (MIDP), combined with the Connected Limited Device Configuration (CLDC), is the Java runtime environment for today’s mobile information devices (MIDs) such as phones and entry level PDAs. What MIDP provides is the core application functionality required by mobile applications?including the user interface, network connectivity, local data storage, and application lifecycle management?packaged as a standardized Java runtime environment and set of Java APIs.

A MIDlet must extend the abstract MIDlet class to allow the Application Management Software (AMS) to control the MIDlet lifecycle and state changes. The methods of this class allow the AMS to start, pause and destroy a MIDlet. A MIDlet is a set of classes designed to be run and controlled by the application management software via this interface. A MIDlet must implement the following three abstract methods as defined in the MIDlet class in order for the MIDlet to be functional:

startApppauseAppdestroyApp

As the names suggest, startApp is called when the MIDlet is entering the active state. pauseApp is called when the MIDlet is about to enter the pause state and destroyApp is called when the MIDlet is about to be destroyed.

The following diagram depicts the states of the MIDlet lifecycle.

A MIDlet programmer is mainly focused on writing code that is executed during the “Active” state and the “Cleanup” code needed for the MIDlet to enter the “Paused” or “Destroyed” states.

What the Code Looks Like
JSR190 is still in its early stage. Therefore, the current APIs are not available to the general public yet and are likely to be changed from their current form. However, some code is provided below to give the readers an idea of how the APIs may appear.

Consider the following pseudo-code.

  public class MyMIDlet extends MIDlet {      public MyMIDlet() {          startup = true;      }	      public void startApp() throws MIDletStateChangeException {          if(startup) {              UsageTracking ut = UsageTracking.getInstance();                // increment the usage counter              ut.incrementCounter(); 			              // Send the event to the server              ut.submit();          }          startUp = false;      }	          public void destroyApp(boolean unconditional) {          notifyDestroyed();      }  }	

In the above example, upon start up of the application, the application usage counter is incremented through the Event Tracking API. Note that the counter is stored locally at this point as submission to the event-tracking server is achieved through another call (see below). Also, the counter is stored persistently and the value should be retained unless the MIDlet is uninstalled. Specific implementation of JSR190 can choose to utilize MIDP’s RMS (Record Management System) to achieve this.

After the counter is incremented, the application can decide when to submit the count to the event-tracking server. In the above example, the count is submitted to the server immediately after the counter is incremented. However, the application can decide when the best time is to submit.

Importantly, it is up to the implementation to optimize the submission. For example, the implementation can combine multiple “submit” calls into a single submission to the server in order to conserve bandwidth. The implementation can also delay the submission until the phone is idle, as certain mobile devices have only limited number of available socket connections. These types of details will be addressed when the specification is finalized.

Not only does the Event Tracking API track how many times the applications has run, it can also be used to track fine grain application events. Consider the following code of a stock ticker program:

  public class StockerTicker extends MIDlet {      public StockerTicker () {      }	      public void checkStock(String url) {          HttpConnection c = (HttpConnection) Connector.open(url);          int code = conn.getResponseCode();          if(code == conn.HTTP_OK) {              // process response here              process(conn);	              // increment the usage counter              UsageTracking ut = UsageTracking.getInstance();              ut.incrementCounter(); 			              // Send the event to the server              ut.submit();          }      }  }	

In the above example, after the stock quote information is successfully processed, the usage counter is incremented accordingly and subsequently submitted to the event-tracking server. It should be noted that the usage counter is quite generic and can be adapted to different type of usages. The Event Tracking API facilitates tracking of various types of application usage that are otherwise not easily registered by server-side only technology.

The Future of JSR 190
Despite the convenience of JSR 190, there are still issues to be addressed. Why not use standardized Web services to accomplish the same thing? This would let operators provide value-based billing in exactly the same way to any device using any language or platform. In addition, using Web service-based billing would simplify the process of letting operators hook into UDDI, so that the “smartphones” themselves could browse for and consume available services automatically.

The advantage of using JSR 190 over Web services is three fold. First, the protocol is very light weight. As bandwidth does cost money, either the end user?or more likely the operator?will have to absorb the cost of transmitting billing information. Therefore, the less traffic it introduces the better. Secondly, one should note the communication protocol between the handset and the server is not Java specific. As a result, the same billing infrastructure can be used for other data services. Finally, JSR 190 can be used in existing MIDP 1.0 handsets today through code instrumentation. Whereas, those wanting to use Web services (JSR 17) for this purpose will have to wait for the handset adopt the technology first. However, over time, the APIs/protocol will evolve to utilize more standardized communication mechanism such as Wireless Web Services (JSR 172).

Streamlined and Flexible
Developers need to be aware of billing models because ultimately the chosen model hits them in the pocketbook. Value-based billing models are flexible?a key ingredient in a developing industry, particularly with the broad range of J2ME applications now being developed. The JSR 190 Event Tracking API provides operators, content providers, and developers with usage statistics that allow monitoring of customer behavior and ground-level information for the next generation of applications. As a standard, the JSR 190 streamlines the tracking methodology and reduces redundancy between interfaces. It can submit the usage information according to the individual application and is adaptable to different types of usages. Indeed, the goal of JSR 190 is simple: help the mobile phone to be as smart as it can be.