Dispatch API that permits midlets to initiate dispatch calls

The present invention can include a method for initiating a dispatch call. The method can include a step of receiving a dispatch call request from a MIDlet disposed within a JAVA™ mobile edition (ME) environment of a communication device, such as a mobile telephony device. The method can determine whether the MIDlet is in a domain having access to dispatch call functions implemented within a native environment of the communication device. When the domain has access, a dispatch communication session can be established for the dispatch call request. The dispatch communication session can execute within the native environment without exiting the JAVA™ ME environment. When the domain lacks access, the dispatch call request can be conveyed to the native environment, the MIDlet can quit executing, the JAVA™ ME environment can be exited, and a dispatch communication session for the dispatch call request can be established from within the native environment.

BACKGROUND

1. Field of the Invention

The present invention relates to the JAVA platform Micro Edition (ME) and, more particularly, to a dispatch API that permits MIDlets to initiate dispatch calls.

2. Description of the Related Art

JAVA platform Micro Edition (JAVA ME) is a collection of JAVA Application Program Interfaces (APIs) for the development of software for resource-constrained devices, such as mobile phones, personal data assistants (PDAs), navigation devices, and the like. JAVA ME devices implement a profile, such as the Mobile Information Device Profile (MIDP), which is part of the JAVA ME specification. Application programs written for JAVA ME virtual machines are called MIDlets. MIDlets are often used to create games and applications for mobile phones.

MIDlet developers often want to be able to write MIDlets that utilize low level capabilities of the host device. Providing access to device resources, however, requires a level of trust between the executing application, the device, and the user. MIDP handles trust issues using protection domains, which are a collection of permissions that can be granted to MIDlets. Standard protection domains include a trusted domain and an untrusted domain. When a MIDlet is installed, that MIDlet is bound to an appropriate protection domain.

One way to establish a level of trust for a MIDlet is to sign the MIDlet using a X.509 based certificate. That is, a MIDlet designer can obtain a public key (PKI) that is used to authenticate the MIDlet upon installation. A number of different certification authorities, such as VERISIGN, GEOTRUST, THAWTE, and the like, exist who can provide public keys that permit MIDlets to be installed within a trusted domain. Unfortunately, different mobile phones behave differently and no current signing authority appears to work seamlessly for every device. Thus, MIDlet designers are left with uncertainty as to whether their MIDlets will be trusted or not, which can prevent these developers from attempting to utilize resources only available when the MIDlet is part of a trusted domain.

Even when a MIDlet designer is granted rights to a trusted domain, many resources of the device are not currently accessible. For example, at present no JAVA ME APIs exist that support Push-To-Talk or dispatch capabilities.

SUMMARY OF THE INVENTION

A JAVA platform Micro Edition (JAVA ME) Application Program Interface (API) for handling dispatch calls. The JAVA API can include a new dispatch initiation method referred to as makeCall, which can be a method of a JavaCall class. When a Push-To-Talk call is initiated using the makeCall method, resulting behavior can be based upon a protection domain to which an invoking MIDlet belongs. For example, when the makeCall method is invoke from an untrusted domain, the JAVA ME environment can be exited and the dispatch call can be executed within a native environment of a mobile device. When the makeCall method is invoked from a trusted domain, the native interface can be called from the JAVA ME environment, where the native interface handles the dispatch call. Processes within the JAVA ME environment can be optionally suspended while the native interface handles the dispatch call.

The present invention can be implemented in accordance with numerous aspects consistent with the material presented herein. For example, one aspect of the present invention can include a JAVA ME API comprising a JAVA ME method. The JAVA ME method can initiate a dispatch call from within a JAVA ME environment of a mobile device. The method can be invoked from an untrusted MIDlet or from a trusted MIDlet, which affects behavior. When the method is invoked from an untrusted MIDlet, the JAVA ME environment can be automatically exited, control can be given to a native environment of the mobile device, and the dispatch call can be completed within the native environment. When the JAVA ME method is invoked from a trusted MIDlet, a dispatch interface that handles the dispatch call can be invoked without exiting the JAVA ME environment.

Another aspect of the present invention can include a method for initiating a dispatch call. The method can include a step of receiving a dispatch call request from a MIDlet disposed within a JAVA ME environment of a communication device, such as a mobile telephony device. The method can determine whether the MIDlet is in a domain having access to dispatch call functions implemented within a native environment of the communication device. When the domain has access, a dispatch communication session can be established for the dispatch call request. The dispatch communication session execute within the native environment without exiting the JAVA ME environment. When the domain lacks access, the dispatch call request can be conveyed to the native environment, the MIDlet can quit executing, the JAVA ME environment can be exited, and a dispatch communication session for the dispatch call request can be established from within the native environment.

Still another aspect of the present invention can include a mobile device having two or more modes and having a dispatch capability that is able to be invoked from a MIDlet. The mobile device can include a JAVA ME environment and a native environment. The JAVA ME environment can include at least one MIDlet, which is installed in a protection domain. The native environment can include at least one dispatch method for establishing a dispatch session. The installed MIDlet can include a JAVA ME method for initiating a dispatch call. When the protection domain is an untrusted domain and when the JAVA ME method is invoked, the JAVA ME environment can be automatically exited, control can be given to a native environment of the mobile device, and the dispatch method can be executed within the native environment. When the protection domain is a trusted domain and when the JAVA ME method is invoked, the dispatch method can be executed without exiting the JAVA ME environment.

It should be noted that various aspects of the invention can be implemented as a program for controlling computing environment to implement the functions described herein, or a program for enabling computing equipment to perform processes corresponding to the steps disclosed herein. This program may be provided by storing the program in a magnetic disk, an optical disk, a semiconductor memory, or any other recording medium. The program can also be provided as a digitally encoded signal conveyed via a carrier wave. The described program can be a single program or can be implemented as multiple subprograms, each of which interact within a single computing device or interact in a distributed fashion across a network space.

The method detailed herein can also be a method performed at least in part by a service agent and/or a machine manipulated by a service agent in response to a service request.

DETAILED DESCRIPTION OF THE INVENTION

FIG. 1is a schematic diagram of a system100for initiating dispatch calls from a JAVA platform Micro Edition (JAVA ME) environment140in accordance with an embodiment of the inventive arrangements disclosed herein. The invention teaches that a MIDlet112can call a method114that initiates a dispatch call. Behavior of the method114depends on whether the MIDlet112belongs to a trusted domain142or an untrusted domain144.

When method114is invoked from a trusted domain142, a dispatch interface154can be invoked for communicating with a layer151of a native environment150, where the dispatch interface154causes one or more dispatch functions152to execute. In one embodiment, JAVA ME environment140processes can be suspended while the dispatch functions152execute, and the suspended processes can resume once the dispatch actions complete.

The untrusted domain144can lack privileges to directly access layer151. Instead, the untrusted layer144can initiate a programmatic action that exits the JAVA ME environment140. One or more dispatch functions152can then be directly invoked from the native environment150. Notably, the one or more dispatch functions152can establish a dispatch session also referred to as a Push-To-Talk session between mobile device130and another mobile device (not shown). This other mobile device can be associated with a phone number specified by method114.

It should be appreciated that application developers110create MIDlets, such as MIDlet112, and place them in a data store118accessible from one or more mobile devices130. Certificate authority (CA)120can issue a key that indicates that a stored MIDlet118is to be trusted. When a MIDlet112is downloaded to device130and installed, it is placed in a protection domain.

A protection domain can determine whether permissions are granted or denied. Standard protection domains include the trusted domain142and an untrusted domain144. Other protection domains exist, such as a minimum domain and a maximum domain, which are defined as part of the emulator included in the J2Me Wireless Toolkit 2.0. In the context of system100, trusted domain142can be any protection domain that allows access to layer151and interface154. That is, trusted domain142allows the environment140direct access to dispatch functions152in native environment152and untrusted domain denies environment140this direct access.

In one embodiment, when the dispatch call is initiated by the mobile device130, a status indicator can be sent to a server of the service provider and/or to an end device that is to receive the dispatch call. This status indicator can indicate whether the invoking MIDlet112is trusted or untrusted. The status indicator can provide additional information about the MIDlet112and/or about the mobile device130, which can cause the service provider and/or the dispatch receiving device to take a further programmatic action. For example, the service provider can automatically send a digital message to a user of device130and/or to a developer of the MIDlet112that indicates that the MIDlet112installed in device130is currently untrusted and that enhanced functionally can be provided if the MIDlet130were certified by an authorized CA120.

As used herein, MIDlet112can be a JAVA program written for embedded devices, and more specifically to a JAVA ME compliant virtual machine. For example, MIDlet112can be a subclass of the javax.microedition.MIDlet.MIDlet class that is defined by MIDP. In the present invention, the term MIDlet112is to be construed broadly to include any standard based upon or derived from the JAVA ME platform and is not to be limited to any particular specification version.

As used herein, JAVA is a platform independent, object-oriented programming language. JAVA code can be compiled into byte code, which can be run within a virtual machine.

The JAVA ME environment140is an environment that includes a virtual machine capable of executing byte code that is configured to run on resource constrained devices, such as device130. Different virtual machines can be customized for a different platforms, which results in software written for environment140being platform independent. The environment140can also include a set of APIs suitable for tailored runtime environments of specific resource constrained devices. In one embodiment, the environment140can permit device130to implement a profile that is aimed at a mobile device, such as the MIDP. As used in system100, JAVA ME environment140can be any edition, version, or derivative of the JAVA platform that is targeted at small, standalone, or connectable consumer and embedded devices. In another embodiment the JAVA ME method is configured to execute from within a single user virtual machine and is also configured to execute within a Multi-user virtual machine (MVM).

Mobile Device130can be a mobile or embedded communication device having dispatch capabilities. The mobile device130can have more than one mode and can therefore be a dual mode or a multimode device. Mobile device130can include, but is not limited to, a mobile telephone, a navigation system, a personal data assistant (PDA), a wearable computer, a media player, a mobile entertainment system, and the like.

CA120can be an entity which issues digital certificates for use by other parties. As such, the CA120is a trusted third party for purposes of a public key infrastructure (PKA) scheme used to certify MIDlet112. Examples of CAs120can include, but are not limited to, Netrust, ENTRUST, PGP, THAWTE, GEOTRUST, DigiCert, and VERISIGN.

In one embodiment, a service provider that provides dispatch services can act as a CA120. Further, the service provider can automatically and dynamically sign or certify MIDlet112, provided that developer110, device130, and/or user specific conditions are met, as established by the service provider. When automatically certified by a service provider, an associated MIDlet112can be placed in trusted domain142.

Native Environment150can be a non-JAVA ME environment of the mobile device130, which includes dispatch functionality. For example, the native environment150can be an Integrated Dispatch Enhanced Network (iDEN) compliant environment or a QCHAT compliant environment. Additionally, multiple different PTT technologies can be utilized by a single mobile device130depending upon resources available proximate to the device130. For example, mobile device130can automatically use iDEN technology by default for PTT functions, but can seamlessly use QCHAT based technology for the dispatch call114when iDEN coverage is unavailable. Further, the environment150is not limited to environments implementing any particular PTT technology. For example, system100can utilize a TALKGROUP based technology, a Selective Dynamic Group Call (SDGC) based technology, a READYLINK based technology, a VoIP PTT based technology, a KODIAK NETWORKS based technology, and the like.

Data store118can be a physical or virtual storage space configured to store digital information. Data store118can be physically implemented within any type of hardware including, but not limited to, a magnetic disk, an optical disk, a semiconductor memory, a digitally encoded plastic memory, a holographic memory, or any other recording medium. The data store118can be a stand-alone storage unit as well as a storage unit formed from a plurality of physical devices. Additionally, information can be stored within data store118in a variety of manners. For example, information can be stored within a database structure or can be stored within one or more files of a file storage system, where each file may or may not be indexed for information searching purposes. Further, data store118can utilize one or more encryption mechanisms to protect stored information from unauthorized access.

The various components (items110,118,120, and130) illustrated in system100can be communicatively linked to each other via a network (not shown). The network can include any hardware/software/and firmware necessary to convey digital content encoded within carrier waves. Digital content can be contained within analog or digital signals and conveyed though data or voice channels. The networks can include network equipment, such as routers, data lines, hubs, and intermediary servers which together form a data or telephony network. The network can include mobile communication components, such as cellular communication towers, two-way radio transceiving components, and the like.

FIG. 2is a flow chart of a method200for initiating dispatch calls in a dual mode device in accordance with an embodiment of the inventive arrangement disclosed herein. Method200can be performed in the context of a system100.

Method200can begin at step205, where a dispatch call method can be invoked from a MIDlet. The method can be a makeCall method of a JavaCall class. The makeCall method can receive a Uniform Resource Identifier (URI) formatted input string. The URI's scheme name can be associated with a dispatch call (e.g. “ptt” for Push-To-Talk) and the scheme specific part of the URI can identify a number that is to be called. For example, the format for the dispatch method of step205can be JavaCall.makeCall (“ptt://number”). In one embodiment, the makeCall method can be overloaded to also handle voice based calls. For example, JavaCall.makeCall (“voice//number”) can initiate a voice based call.

In step210, a determination can be made as to whether the MIDlet initiating the dispatch call is trusted. If not, the method can branch to step215, where a platform request ( ) method can be utilized to initiate a dispatch call. The input string for the platformrequest ( ) method can be formatted in the same manner as the input string used by the makeCall method. In step220, before an exit from the JAVA ME environment occurs, the dispatch call can be confirmed. Additionally, any JAVA settings can be optionally saved as necessary. In step225, when the dispatch call is confirmed, JAVA ME processes can quit, control can be passed to a native environment that implements the dispatch call, and the dispatch call can be made.

When the MIDlet of step210is trusted, the method can proceed to step230, where a call to a native interface can be made. For example, an INativeNumberEntry interface can be called. In step235, JAVA processes can be optionally suspended. In step240, the dispatch call can be made. In step245, the dispatch call can end and any previously suspended JAVA processes can be resumed.

It should be appreciated that step205of invoking the dispatch call method can occur responsive to many different conditions. For example, a user of a mobile device can select an option to invoke the dispatch method from within a JAVA ME based interface. In another example, an application executing on the mobile device can automatically initiate the dispatch method based upon occurrences of previously established conditions without requiring an explicit user selection of a dispatch initiation option.

In still another example, a mobile terminal can receive a dispatch request via an electronic message, such as an email message, a Short Message Service (SMS) message, a Multimedia Message Service (MMS) message, an ASCII/Unicode message, and the like. The electronic message can include an embedded URI string (e.g., ptt://number) for initiating a dispatch. This string can be interpreted by a browser element or an application management system (AMS) as a dispatch call. The element or AMS can apply the method200or can launch JAVA to handle an associated MIDlet, which in turn handles the dispatch request in accordance with method200.