Host extensible wireless application interface

[0001] This application claims priority based on provisional application serial No. 60/346,917 Dkt. No. 034300-170, entitled HOST EXTENSIBLE WIRELESS APPLICATION INTERFACE by Richard Wodzianek and Parampreet Sandhu filed on Jan. 11, 2002.

[0002] 1. Field of Invention

[0003] The present invention generally relates to wireless devices and more particularly to a runtime environment for the wireless device that executes applications on a host device.

[0004] 2. Status of the Prior Art

[0005] Application development environments have been designed to allow application developers to exploit the internal functions of wireless devices. Accordingly, API's (application programmer's interface) allow developers to design applications that access internal functions of wireless devices such as GPS, Bluetooth, WAP browser, Instant Messaging, multimedia, games, etc . . . of a wireless device. An example of an application development environment is the Binary Runtime Environment for Wireless (BREW) created by Qualcomm. The BREW API is an object-oriented platform supporting simple application execution on mobile devices that decouples applications from wireless device specific events.

[0006] The BREW API is an applications platform for wireless devices that is a very thin, standardized platform which supports application development for the large and growing CDMA handset market. Accordingly, the BREW API can support inexpensive, mass-market phones through high-end, multi-purpose wireless devices. The BREW API provides a familiar development environment for applications developers that protects essential operations of phones and wireless networks. Furthermore, the BREW API enables rapid development of a wide variety of downloadable applications. Currently, the BREW API is available only on CDMA handset products such as cellular phones. Because it is not an operating system, but a set of libraries that form an API, the BREW API is dependent upon the underlying CDMA platform.

[0007] The BREW API operates within the smartphone paradigm and runs on top of a MSP (Mobile Station Processor) and MSM (Mobile Station Modem) of the wireless device. Referring to FIG. 1, the handset platform 10 for a mobile device is shown. The handset platform 10 supports a BREW application 12 on the top layer. The BREW application 12 is created by the application developer and can be run by the wireless handset. For instance, the BREW application may be a sound player, map viewer, game, or any type of application that takes advantage of the features of the wireless device. The BREW applications 12 run on top of the BREW API 14, as seen in FIG. 1. The BREW API 14 is part of the runtime environment available in CDMA based wireless handsets. BREW API 14 runs on the CDMA mobile station modem chipset which includes the MSM and MSP.

[0008] Referring to FIG. 2, the handset platform 10 is shown in greater detail. The platform 10 includes BREW applications 12 which run on top of the BREW API 14 and OEM UI applications 18. The BREW API 14 interacts with an OEM user interface 20 and handset specific modules 22 such as sockets, EFS, call managers and wireless Internet launchpad. In the same layer as the handset specific modules 22 are OEM drivers 24 for the handset. As seen in FIG. 2, wireless handset specific modules 22 or features are made available to application 12 via the BREW API 14.

[0009] Often times, the mobile device such as a PDA or laptop computer will contain a wireless device such as a CDMA wireless modem. In this regard, the mobile device (i.e., PDA) will not run the handset platform 10 previously described. Typically, the mobile device will run it's own platform. For example if the mobile device is a PDA, then the device will use Microsoft's PocketPC operating system using PC Card and embedded module form factors. BREW applications 12 designed to be run utilizing the BREW API 14 run on the handset platform 10 will not function properly on the mobile device. The BREW applications 12 will not function on mobile devices that have wireless capability because the devices do not run the mobile handset platform 10 as previously described. Accordingly, PDA's and laptops that have wireless capabilities will not be able to utilize BREW applications 12.

[0010] The present invention addresses the above-mentioned deficiencies in the current architecture for mobile devices by providing a host extensible wireless application interface that is run by the host of the wireless device. The present invention provides a system and method for providing a way to run the BREW API 14 on a mobile device even though the mobile device does not utilize the handset platform 10. Accordingly, the present invention provides a system and method for a mobile device to run BREW applications 12 without utilizing a handset platform.

[0011] In accordance with the present invention, there is provided a system and method to run applications created for the Binary Runtime Environment for Wireless (BREW) on a host operating system of a mobile device. The present invention provides a BREW API translation layer which allows native BREW applications to run on a host specific operating system rather than a wireless handset platform operating system. The translation layer provides a method for the BREW application to access commands of the wireless device, even though the wireless device is not running a wireless handset platform. This is extremely advantageous when the wireless device is a wireless modem card inserted into a PDA. The BREW applications can then be seamlessly run on the PDA while utilizing the functions of the wireless modem. The translation layer further provides a method for extending the functionality of the BREW application.

[0012] These as well as other features of the present invention will become more apparent upon reference to the drawings wherein:

[0013] FIG. 1 illustrates a handset platform architecture for a binary runtime environment for a wireless device;

[0014] FIG. 2 illustrates the architecture of FIG. 1 in greater detail;

[0015] FIG. 3 illustrates the architecture of a system utilizing a wireless device such as a CDMA device but not having a handset platform; and

[0016] FIG. 4 is a flow diagram showing how translation occurs in the present invention.

[0017] Referring now to the drawings wherein the showings are for purposes of illustrating a preferred embodiment of the present invention only, and not for purposes of limiting the same, FIG. 3 illustrates an architecture 100 for a mobile device having a host specific operating system 120 that is not a handset platform. For example, the host specific operating system 120 may be Microsoft's PocketPC that is run on PDA's. Referring to FIG. 3, native BREW applications 112 and applications that extend functionality 118 run on the top layer within the host specific operating system 120. As previously mentioned, BREW applications 112 are programs designed to be run on a wireless handset device. The applications that extend functionality are programs which take advantage of the unique operating features of a device and are not generic to BREW applications 112. For instance applications can take advantage of enhanced wireless capabilities specific to certain CDMA devices (i.e., IS-95A/B, 1xRTT, 1xEVDO), GPRS and UMTS implementations.

[0018] Below the BREW Application 112 is the BREW PI 114 which operates on the BREW applications 112, as previously discussed. Furthermore, in this layer are extensions to BREW functions 122 which operate on the extended applications 118. Accordingly, the BREW API 114 and the extensions to BREW functions 122 are operative to run the respective native BREW applications 112 and functionally extended applications 118.

[0019] In order to translate the commands from the BREW API 112 for use by the host specific operating system, the architecture 100 further includes a BREW API translation layer 124 below the BREW API 114, as seen in FIG. 3. During operation, native BREW applications 112 call functions specified in the BREW API 114 which is a reference library. The BREW API translation layer 124 will accept the binary format of the function call from the BREW API 114 and perform the appropriate translation of function and parameters. The translated functions and parameters will then be sent to a control and status protocol layer 126 that monitors and controls the operation of a CDMA device 128. The translated function calls are then sent to the CDMA device 128 for execution by the CDMA mobile station modem chipset 116. As previously mentioned above, the CDMA device 128 may not be a wireless handset but may be a wireless modem that utilizes the host specific operating system 120 for operation. The BREW API translation layer 124 performs the necessary translation of commands such that BREW applications can be executed by the CDMA device 128. Furthermore, the BREW API translation layer 124 can translate commands from the CDMA device 128 to the BREW application 112.

[0020] For example, referring to FIG. 4, the native brew application 112 may make a function call. The function call is received by the BREW API translator 124 which then calls the equivalent function call from its API DLL (dynamic linked library). The result will be a message or command response sent to the CDMA device 128. Additionally the process can be reversed. For instance a command/response from the CDMA device 128 is processed by the API DLL of the BREW API translator 124 into the corresponding function call for the BREW application 112.

[0021] By utilizing the BREW API translation layer 124, mobile wireless users are no longer restricted to running applications on handsets with limited text entry and minimal graphics and display capabilities. Instead, users and application developers will be able to leverage the multi-media capabilities of PDA's and portable computers. Furthermore, with the ability to use extended applications, BREW is extended to other wireless technologies such as GPRS and UMTS.

[0022] As for an implementation, the varieties are numerous. In one embodiment, the portions are implemented as software residing in a memory and accessible to an operating system and to the host processor. Or, in another implementation, the portions can be implemented in progammable or non-programmable hardware. Or, any combination of hardware or software may be implemented.

[0023] The steps of the method may be stored or performed from various medium readable by the host device. This may take the form of portable media, such as a floppy disk, CD-ROM, DVD-ROM, or any manner or optical or magnetic media. Or, the specific instructions may be stored in a semiconductor memory.

[0024] Thus, the particular combination of parts described and illustrated herein is intended to represent only a certain embodiment of the present invention, and is not intended to serve as a limitation of alternative devices within the spirit and scope of the invention.