CN1309787A - Changing the functionality of modular terminals in wireless networks - Google Patents

Abstract

The functionality of the portable wireless device can be changed by providing a program written in a language such as Java and generating a verifiable intermediate code (bytecode). The intermediate code is translated into machine code at a node in the network before being transmitted to the wireless device on which it is to be executed. There may be multiple variations of machine code for each program that are translated using translators for different types of terminals. This allows different terminal types to use the same source code and to divide responsibility between software providers, terminal providers and network operators involved in changing the functionality of the device to perform different functions, i.e. developing the source code of the program, compiling the source code into byte code, translating the byte code into machine code and transmitting the machine code to the terminal on which it is to run.

Description

Changing the functionality of modular terminals in wireless networks

The present invention relates to the provision of services, and in particular to the provision of services to hand-held or portable terminals in a wireless network.

The use of mobile phones for various purposes is increasing. Many new types of mobile or portable terminals have been promoted, such as smart phones, messenger notes, personal digital assistants, smart pagers, and the like. Terminals are constantly being developed with new functions added. However, the possibilities for upgrading the functionality of existing mobile terminals are limited by the prior art.

Accordingly, there is a desire to be able to increase the functionality of existing portable terminals and adapt the functionality to suit the needs of users. The general requirement for portable terminals is to be as small and lightweight as possible. This limits the memory space available, as well as processing speed and power. Other factors, such as limited battery capacity and the need for cooling must also be considered.

Current developments in portable devices attempt to place the intelligence of the system in the portable device itself rather than in the server, with the goal of making user interaction faster and reducing the bandwidth required to deliver information and functionality. However, there is a limit to the amount of memory and processor capacity that can be accommodated in a portable device without increasing the size and weight of the portable device too much. Therefore, when designing a mobile terminal, a balance must be found between the functional requirements of the terminal and its size, weight, etc. In determining what is stored in the mobile terminal and what is stored in the nodes of the network, there is a trade-off between the processor capacity and memory space required by the portable terminal and the bandwidth required to transfer programs and/or information between the network and the portable terminal. A balance has to be found.

Furthermore, there are a large number of different terminal types using different hardware and software platforms. Therefore, it is desirable for a program to be executable on several different platforms.

It is an object of the invention to enable more advanced or more demanding programs to be executed in a portable device than is normally possible with respect to the processor power and memory space of the portable device.

It is an object of the present invention to allow programs to be executed in a small device having limited processor power and/or memory space without reducing the processing speed.

Another object of the present invention is to be able to add new functions, upgrade functions, or completely replace function packs in different types of handheld devices, especially those suitable for use in cellular networks.

Yet another object of the invention is to be able to execute programs that do not have to be permanently stored in the terminal.

According to the invention, these objects are achieved by a method of changing the functionality of mobile terminals connected via wireless connections in a network,

said functionality is realized by a program written in the same programming language, whose source code can be compiled into an intermediate code, said intermediate code being executable and verifiable,

The method includes the following steps:

- translating said program into machine code using at least one translation program associated with the hardware and software environment of at least one terminal type;

-downloading the translated program to the aforementioned mobile terminal.

These objects are also accomplished by an apparatus for providing a program in a network comprising a plurality of hosts and a number of different types of terminals, at least some of which are connected by wireless connections, said program being written in a programming language implemented, its source code can be compiled into an intermediate code that is executable and verifiable, and can be interpreted or translated into machine code:

Said equipment includes:

- memory means for storing the program in machine code form in such a way that the program can be executed in at least one type of client terminal in the network,

- means for transferring the program to at least one client terminal, said program being in the form of machine code.

According to a preferred embodiment, the aforementioned device also comprises at least one translation program for the intermediate code, said translation program being adapted to at least one hardware and software environment used by the terminals in the network.

According to this embodiment, the method further comprises the step of translating said program using at least one translation program in the host computer before storing the program.

Programs can be downloaded to the terminal automatically or upon request from the end user.

The method is particularly useful for portable terminals in cellular telecommunication networks.

According to a preferred embodiment, the suitable program variant to be downloaded to the terminal is determined on the basis of the type of terminal, eg on the basis of the terminal's identification code.

These objects are also achieved by a portable terminal suitable for wireless communication, comprising a kernel designed to receive programs and/or program parts in machine code form and to install the received programs in operation.

The portable terminal may be designed to provide the user with information about the correlation tree of available programs.

The portable terminal can also be designed to inform the appropriate nodes in the network of its type and the type of subscription it is currently running, as well as other information, such as its current battery status.

According to a preferred embodiment, the portable terminal according to the present invention also receives and interprets information on whether a program or a program block should be stored in the portable terminal.

The most commonly used language of the above types is currently Java. Other examples are LISP, SmallTalk, and Erlang. For certain types of processors, the source code of a Java program is not compiled to form machine code. It is compiled into short pseudo-instruction "byte codes" used by the virtual machine. When a program is to be executed, the bytecode is typically downloaded to the terminal on which it will be run and then converted into machine code for that terminal. In this way, programs written in an interpreted language like Java can be executed on any type of computer that has a translator or interpreter for that language.

Java is primarily used for applications on the Internet, but the advantages of interpreted languages allow them to be used in cellular networks as well. Java programs are generally smaller than corresponding machine code programs, and thus are suitable for mobile terminals because the available storage space of mobile terminals is limited. More and more mobile terminals support Java applications.

Utilizing interpreted languages like Java is particularly feasible in portable terminals because their memory space is limited. Translating programs outside of the terminal also reduces the processing speed and power requirements, which are also limited in portable terminals.

A major advantage of the invention is that it enables the division of responsibility for performing different functions that involve changing the functionality of the device. For example, a software manufacturer may be responsible for developing the program's source code and compiling the source code into byte code. The manufacturer of the mobile terminal can be responsible for translating the byte code into machine code, and the network operator can be responsible for transferring the machine code to the terminal on which the code will be run.

Interpreted languages such as Java have many advantages:

- they make it possible to load and unload parts of code dynamically thus reducing the amount of space required,

- they facilitate the exchange of parts of said software, since dynamic linking of programs is easier than in other programming languages, and

- They enable the same byte code to run on different processors and under different system architectures, so that a specific function only needs to be programmed once.

The last two points are useful for all portable devices, but especially for those that can communicate with some kind of wireless network, because they will be able to take advantage of all types of services that the network offers. Likewise, downloading a new program makes it easy to upgrade the software, which also prevents the terminal from becoming obsolete due to function upgrades or new services being developed. It will also make it easy to change from one operator to another, in which case the new operator's business package will replace the old one. It can also be seen that the services offered by mobile operators can vary according to, for example, the time of day, the error status of base stations in the area, the availability of Internet-related services, and the like.

Figure 1 is a simplified diagram of a network to which the method according to the invention is applied.

Figure 2 is a more complete diagram of a network applying the method according to the invention.

Figure 3 is a flowchart of the process of making a new service available in the network according to the present invention.

Fig. 4 is a flowchart of the process of automatically downloading a new service to a terminal according to the present invention.

Fig. 5 is a flow chart of the process of downloading a new service to the terminal according to the user's request according to the present invention.

Figure 6 is an overview of how responsibilities are divided among the different actors according to the invention.

Figure 1 is a simplified diagram of a network to which the method according to the invention is applied. The portable terminal 1 is connected to the mobile network via a base station 3 via an air interface. The base stations are connected to a control unit 5 which in turn is connected to a network (not shown). The control unit 5 controls the base stations and performs resource allocation functions and other functions, such as switching functions in the mobile telecommunication network. There is a program delivery unit 9 in or associated with the control unit 5 .

The control unit 5 is connected to one or more hosts 7 of a hardware provider, which in turn are connected to a host 8 belonging, for example, to a software provider. Typically, the software provider's mainframe 8 is used to generate source code and compile the source code into byte code. The byte code is then transferred to the hardware vendor's host computer 7 where it is translated into machine code. For this purpose, each hardware vendor host computer 7 includes one or more translation programs for each type of terminal of at least a particular hardware vendor. In the hardware provider's mainframe 7 and the software provider's mainframe 8, both normally carry out various testing activities in a manner known in the art.

In the above discussion, the division of various functions into the host 7 of the hardware supplier, the host 8 of the software supplier, and the control unit 5 or program providing unit 9 is mainly done to distinguish the different functions implemented. Of course, the hosts 7 and 8 could also be a host in which the source code is both compiled and translated. In addition, the translation function can also be implemented in the program supply unit 9 , in which case the program supply unit must include at least one translation program 11 .

The program providing unit 9 includes a plurality of programs 13 , 15 . Each program has several variants 13a, 13b, 13c, 15a, 15b, 15c which are translated by different translation programs 11 for execution in different types of terminals 1 .

Or, just store the byte code. In this case, when a program 13, 15 is to be downloaded to the portable terminal 1, this program 13, 15 is translated by an appropriate translation program 11 so as to be executable on the terminal 1, and the resulting machine code is transferred to the terminal 1. This process will be discussed in detail in conjunction with FIGS. 4 and 5 . Either one of the program providing unit 9 or the control unit 5 preferably includes a selection unit, which includes options for determining suitable variants 13a, 13b, 13c, 15a, 15b, 15c of the programs 13, 15 to be transmitted to the terminal 1. logic. In FIG. 1 such a selection unit 17 is shown in the program providing unit.

Figure 2 is a more general representation of a network implementing the method according to the invention.

This network may comprise several networks, such as a telecommunications network 21 and a data network 23, which may be, for example, the Internet. In Figure 2, the telecommunications network 21 is a cellular telecommunications network. The telecommunications network 21 comprises one or more communication units 25, such as base stations, connected to the network via a control node 26, which controls the functions of the communication units 25 and possibly other functions, such as switching functions in the network. The communication unit 25 is adapted to wirelessly communicate with a terminal 27 in the network.

The data network 23 also includes a plurality of terminals 29, 31, some of which are used to provide programs in source code or byte code form. Other terminals 31 can retrieve various programs that have become available according to the present invention.

The control node 26 also contains various programs that can be downloaded to the terminals 27 in the cellular network 21 . In the preferred embodiment, translated versions of the programs are downloaded to the control node 26 and stored there. Programs may also be downloaded to the control node 26 in byte code form, translated in the control node 26 and then stored there as machine code. Programs can also be downloaded into the control node 26 and stored in byte code form. In the latter case, the byte code must be translated into machine code when the program is to be downloaded to the terminal.

As will be understood, any terminal 27, 31 connected to either network 21, 23 can also download programs from any host computer 25, 29 in either network, assuming such Do the desired functionality is able to get words.

In this embodiment, one selection unit 33 is shown in each control node 26 . The selection unit 33 comprises logic for selecting a suitable variant of the program to be transferred to the terminal 27 . If translated programs are stored, the selection unit may also include or have access to a list of appropriate variants of the program for each terminal type and/or subscription. If byte code is stored and the program is translated at the time of transmission, the selection unit may contain or have access to a list specifying which type of translation program. The list can of course also indicate that a particular terminal type and/or subscription should not receive any variant of a certain program.

Figure 3 is a flowchart of the steps taken to make a new program available in the network.

Step S31: Write the source code of the business program in Java or other interpreted languages.

Step S32: The source code generated in step S31 is compiled to generate byte code. This step usually includes security checks, error detection, functional testing, debugging, and more.

Step S33: The bytecode generated in step S32 is downloaded to the server, where the bytecode is stored. This step should generally also include security checks.

Step S34: The business program is translated by each available translation program. Of course, if business programs are not to be run on all types of terminals, then of course they only need to be translated by the relevant translation programs.

Step S35: The machine code resulting from step S34 is stored somewhere, from where it can be downloaded to a portable terminal or other device.

If the storage space of the control node 26 is limited, it is not possible to store many different translations of the program. In this case, the program can be stored in the form of byte code. The translation of the byte code is then performed when it is downloaded to the terminal, that is to say, steps S34 and S35 are not required. Of course, it is also possible to explain the programs before they are downloaded to the server storing them, that is to say, the order of step S33 and step S34 can be interchanged.

Figure 4 is a flowchart of the steps performed when a service is automatically downloaded to a portable device.

Step S41: The system notifies the user that it may wish to download a program and asks for confirmation. This may be due to, for example, a new program or a new version of the program being available, or because the user has selected a function which requires a program which is not found in the user's terminal.

Step S42: The user accepts or rejects the download of the new program version.

Step S43: If the user accepts the download, select a program variant suitable for the terminal type and cause the program to download. The process is over.

FIG. 5 is a flow chart of steps performed when a service is to be downloaded to the portable terminal to execute or store a program according to the user's request.

Step S51: The user initiates a connection between the device to download the program and the server storing the program. This can be accomplished via an air interface or a wired connection by any means known in the art.

Step S52: Determine the type of the terminal. This is preferably done automatically by the system, but the type of terminal can be specified by the user if desired.

Step S53: If appropriate, the user selects one or more programs to be downloaded.

Step S54: Identify and download corresponding variants and versions of the one or more programs selected in step S53. If the programs are stored in byte code on the server, they must be translated by a suitable translation program when downloaded. The process is over.

Programs can be temporarily stored in the terminal to be cleared once they are executed, or programs can be stored in the terminal.

The selection of the appropriate program variant in steps S43 and S54 can be performed by the communication unit, or this information can be retrieved from the supplier of the terminal or from the software supplier.

The programs that can be downloaded to a particular terminal, or suitable variants of each program, can be determined according to the type of terminal and the type of subscription.

Information about the type of subscription is found on a chip in the phone and is always transmitted to the base station when a connection is established. This chip (eg SIM card in GSM) is generally removable and can be inserted into a number of different terminals. Therefore, the type of terminal cannot be determined from the information on the chip. However, different types of terminals may run different programs and require different variations of each program, even for the same type of appointment.

The terminal type can be determined either automatically or by manual identification. In the latter case, for example, each terminal type can be assigned an identification number which is entered each time a program is to be downloaded.

In the preferred embodiment, the terminal type is determined using the terminal's identification code, which is a unique number that identifies the wireless terminal. In GSM, for example, the International Mobile Equipment Identity (IMEI) may be used. This number (IMEI) is stored in each mobile terminal and should in this case be transmitted by the mobile terminal to the network to indicate the program variant it is to receive. It is also possible to specify multiple terminal types and enable each terminal to inform the system of its terminal type. In order for this method to work, information about the requirements of each series of terminals must be provided by the manufacturer of the terminals and stored in each host, or retrieved from the manufacturer whenever required. This information may take the form of instructions for translation programs available for each terminal type. Translators may be provided by the terminal's manufacturer, in which case it is only necessary to identify a suitable translator. If the terminal manufacturer does not provide a translation program, the requirements for the translation program must be specified in detail.

The program to be downloaded may also be determined according to other factors, such as the identity of the cell, the operator, the time or date of the day, and the like.

Automatic downloading of programs can be used, for example, in the following situations:

- When a package has been updated, each terminal can download the package to the terminal when it connects to the network for the first time after the package update.

- When a user tries to start a service, the program associated with this service can be downloaded without the user explicitly notifying this first.

- Certain programs may be downloaded automatically depending on location, time of day, operator, etc.

In the first case listed above, if the user does not wish to receive new software, then he/she should have the possibility to stop the download of the software. This can happen, for example, due to lack of time or due to low battery voltage. Downloads can also be stopped automatically, for example, if the battery voltage is too low.

When the telephone user is connected to another network than the one that recognizes him/her as a user (for example when traveling abroad), this situation can be handled differently. In this case, the subscription information sent lets the system know that the user does not belong to the current network. Even if automatic downloads are not possible, it is desirable to allow software to be downloaded on request.

The transfer of the program from the host to the terminal can be done according to the existing protocols for data transfer in the systems concerned. For example, in GSM, a protocol for packet communication, Global Packet Radio Service (GRPS), may be used. In Advanced Mobile Phone Service (AMPS) systems, the Cellular Digital Packet Data (CDPD) protocol may be used. The latter protocol also includes the ability to suspend data communication when a voice call is attempted.

The transfer of the program to the mobile terminal can be done on any available channel. In order to transfer programs from a communication unit to a mobile terminal at a given time, traffic channels can be used. Of course, the data can be transmitted according to a circuit-switched protocol or according to a packet-switched protocol (eg GPRS in the GSM system). Alternatively, high speed connections comprising more than one traffic channel, such as High Speed Circuit Switched Data (HSCSD) in GSM, may also be used. This will make program transfers faster, but it may only be feasible when the traffic load on the network is relatively low.

Broadcasting can be used when the same program is to be transferred to multiple mobile terminals at the same time. In this case, control information must be added to let the mobile terminal know which type of terminal is to receive the program, and each terminal must contain logic capable of determining whether the program is intended for that particular terminal.

Portions of program code (particularly those that are to be run multiple times) may in some cases be stored temporarily or permanently to avoid having to download them each time they are run. For example, a subroutine in a program that is executed many times while the program is being executed may be temporarily stored in the portable terminal while the program is running. Programs that perform important functions can be stored permanently or semi-permanently.

The portion of the program to be stored in this manner can be selected by the user or by a node in the network, but is preferably selected cooperatively by both. There are several methods known in the art to do this. For example, each program or program part can be marked to indicate whether it should be stored in the mobile terminal from a system point of view (for example, to save bandwidth). However, in order to determine whether a program or program part should be stored in the mobile terminal, knowledge about the state of the terminal is also required. Therefore, it is generally not possible to automatically store these program parts without giving the user an opportunity to interrupt.

If the user wants to delete a program or program part, he/she must have information about the dependency tree, that is, what other programs or program parts use the program or program part to be deleted, since this determines the Whether the program or program part should really be deleted.

Therefore, the mobile terminal should contain functions that enable the user to determine whether and for how long a particular program or program part should be stored, and provide the user with the information needed to make a decision.

FIG. 6 illustrates the division of responsibilities for providing programs according to the present invention.

The service provider 101 provides suitable source code or byte code. To do this, the service provider 101 must know the functions required by the service to be provided. Detailed information about the software and hardware environment provided in the terminal is not required, but basic information about the terminal (eg its capacity) may be useful.

The terminal manufacturer 103 supplies the terminal and usually also provides a translation program suitable for the programming language of the terminal he supplies. The terminal manufacturer 103 must have knowledge about the programming language used. Of course, there will be several service providers and terminal manufacturers.

A network operator 105 is responsible for the mobile network 107 and for providing services to users 109 in the network 107 .

Responsibilities can be divided between the service provider 101, terminal provider 103 and network operator 105 in many different ways. For example, the service provider 101 may provide the byte code to the terminal manufacturer 103 as indicated by arrow 111 . Then the terminal manufacturer 103 utilizes his suitable translation program provided for the terminal to translate the byte code into machine code, and this machine code is provided to the network operator 105 through a transmission network 113 such as the Internet, as indicated by arrow 115 Show. Of course, the machine code may be provided by any means known in the art, for example, by direct connection or floppy disk, or CD-ROM.

Another way of dividing responsibility may be that the service provider 101 directly provides the byte code to the network operator 105 through the transmission network 113 , as shown by the arrow 117 . The terminal manufacturer 103 can provide the translation program to the network operator 105, and the network operator 105 can translate the byte code into machine code.

In either approach, the machine code can be stored in memory 119 and provided to user 109 via cellular network 107 as indicated by arrow 121 when needed. Of course, the service provider 101 can also send source codes instead of byte codes, but generally speaking, it is not desirable to send source codes.

Claims (23)

1. A method of changing the functionality of a mobile terminal connected via a wireless connection in a network, said functionality is implemented as a program written in a programming language whose source code can be compiled into intermediate code, said intermediate code being executable and verifiable, It is characterized by the following steps: - translate the above-mentioned intermediate code into machine code by using at least one translation program related to the hardware and software environment of at least one type of terminal; - determining suitable variants of machine code to be downloaded to the terminal; - Download the appropriate variant of the machine code to the above mentioned terminal. 2. A method according to claim 1, characterized in that - translating said program into machine code using at least one translation program as described above; - storing the machine code of the above program in a host computer in the network; - transferring said machine code to at least one of said terminals when required. 3. 2. A method according to claim 1 or 2, wherein the downloading of the program is initiated by a unit in the network. 4. A method according to claim 1 or 2, wherein the program is downloaded to the terminal in response to a request from a user of the terminal. 5. A method according to any one of the preceding claims, characterized in that at least some of said terminals are portable terminals used in a cellular telecommunication network. 6. A method according to any one of the preceding claims, characterized by the step of determining whether a program block should be stored temporarily or permanently in the terminal, and if this is the case, storing the program accordingly. 7. A method according to any one of the preceding claims, characterized by the step of determining on the basis of the identification code of the terminal a suitable variant of the machine code to be downloaded to the terminal. 8. A method according to any one of the preceding claims, characterized by the step of determining, on the basis of the code identifying the type of subscription, a suitable variant of the machine code to be downloaded to the terminal. 9. A method according to any one of the preceding claims, characterized by the following steps: - For each program, determine the type of terminal on which the program can be used; - Translate the program using the translator associated with said terminal type. 10. A device for providing a program in a network comprising a host computer and a number of different types of terminals, at least some of which are connected to the rest of the network by wireless connections, said program being programmed language, its source code can be compiled into intermediate code, said intermediate code is executable and verifiable, and can be interpreted or translated into machine code: Said device is characterized in that it comprises: - storage means for storing the program in the form of machine code executable on at least one type of terminal in the network; - Determine which machine code should be downloaded to a particular terminal based on the terminal type; - Means for transferring the program in machine code form to at least one terminal. 11. 10. Apparatus according to claim 10, characterized in that it comprises translation means for translating the intermediate code into machine code in such a way that it can be executed on at least one type of portable terminal in the cellular network. 12. 11. Device according to claim 10 or 11, characterized in that at least one type of terminal is a portable terminal connected in a cellular network. 13. 10. Apparatus according to any one of claims 10-12, characterized in that it comprises means for determining the type of terminal on which each program can be used. 14. 13. Apparatus according to claim 13, characterized in that it comprises means for determining the machine code to be downloaded to a particular terminal on the basis of the serial number of the terminal. 15. 10. An arrangement according to any one of claims 10-14, characterized in that it comprises means for determining the program to be downloaded to a particular terminal on the basis of the subscription type used by the terminal. 16. A telecommunications network comprising a host and several types of terminals, at least some of which are connected to the rest of the network by wireless connections, the network being characterized in that it comprises: - at least one translation device for a programming language whose source code can be compiled into intermediate code, said translation device being used to translate said intermediate code into a machine executable on at least one of said terminals code; - memory means for storing machine code; - means for determining what program or program version should be downloaded to a particular terminal; - means for transferring the program in machine code form to at least one terminal. 17. 16. A telecommunications network according to claim 16, characterized in that it comprises means for determining on the basis of the type of terminal what program or program version should be downloaded to a particular terminal. 18. 16. A telecommunications network according to claim 16 or 17, characterized in that it comprises means for determining on the basis of subscription type what program or program version should be downloaded to a particular terminal. 19. A portable terminal suitable for wireless communication, comprising a kernel adapted to receive programs and/or program parts in machine code form, characterized in that said kernel is designed to install the received program and/or part of the program and is designed to inform the appropriate nodes in the network of its type and/or the type of subscription it is currently operating on. 20. 19. Portable terminal according to claim 19, characterized in that it is designed to provide the user with information about the dependency tree of the programs available. twenty one. A portable terminal according to claim 19 or 20, characterized in that it is designed to inform the appropriate nodes in the network of its type and the type of subscription in which it is currently operating. twenty two. A portable terminal according to any one of claims 19-21, characterized in that it is designed to inform appropriate nodes in the network about its current battery status. twenty three. A portable terminal according to any one of claims 19-22, characterized in that it is designed to receive and interpret information as to whether the program or program blocks are to be stored in the portable terminal.

Images