WO2003073273A1

WO2003073273A1 - Decentralised and customised service management method and device

Info

Publication number: WO2003073273A1
Application number: PCT/FR2002/000742
Authority: WO
Inventors: Hong Tak Choi; Min Tan Min; Uen Jye Ng; Justine Chia En Chiu; Moh Jeng Lee; Pao Swee Tan; Choon Khiang Tang; Chee Leong Liew
Original assignee: Gemplus
Priority date: 2002-02-28
Filing date: 2002-02-28
Publication date: 2003-09-04
Also published as: AU2002241075A1

Abstract

The invention relates to the management of application programs, said programs being constructed from command modules that represent basic high-level commands. The invention is particularly suitable for GSM-type devices in which a static part of the application program is stored within the device and another dynamic part is stored on a remote server.

Description

METHOD AND DEVICE FOR DECENTRALIZED AND PERSONALIZED SERVICE MANAGEMENT

The invention relates to the management of so-called application programs which represent services offered by entities commonly called service providers or content providers.

More particularly, the invention is suitable for application programs (or more simply called "applications") intended for devices connected online to a remote source, such as second or third generation mobile telephone terminals within the framework of a transaction. A first characteristic of these devices is the low memory space and the low computing power that they have. A second . characteristic is that they have a means of communication for digital data. For the sake of clarity, we will present the invention later in the context of mobile telephony, in a non-limiting manner.

Currently, the application programs of these devices are mainly stored in their SIM smart card (English acronym for "subscriber identity module") and are divided into two categories: static programs, which reside entirely on the card and are executed locally, and dynamic programs, which provides for interaction with a remote server. In the first case, the application program is entirely stored on the card. Its execution takes place locally and autonomously. This solution has obvious limits due to the lack of possibility of taking into account data which change over time. In addition, updating the program and / or program data itself is complicated.

To solve the previous problem, dynamic applications, which consist of two parts, are used: the first part, called static, is stored on the card, and the second part, called dynamic, on a remote server. This second part can advantageously process the evolving digital data, the value of which changes regularly as a function of time, as well as parts of the program representing rarely used options. The execution of such a program on the card calls in real time on the dynamic part when necessary. There is then remote downloading of the dynamic part requested, by means of messages in SMS format, acronym of the English expression “Short Message Service”. The set is built using the navigation technique, like web pages on the Internet, and using XML-like language. Each static page of the application program represents a file of the smart card and each dynamic page is downloaded by SMS when necessary. Optimizing such an application involves finding the compromise between static pages and dynamic pages. A large number of static pages has the drawback of requiring a large memory space locally. A large number of dynamic pages has the drawback of causing slowness and heaviness of execution by the need for numerous SMS exchanges, each being limited in size to 140 net bytes, and also of causing errors due to bad message receptions. In practice, the service provider and the communication operator decide in advance the compromise for each service and predict the number of files needed on cards to accommodate static pages. As the margin in memory space on such cards is generally zero, the user does not have much subsequent possibility to modify this initial choice. In addition, when the latter wants dynamic data, he must download at least one web page, even if he is not interested in the whole page. This management of the service is centralized and has drawbacks for its user.

The object of the invention is to propose a solution which does not have these drawbacks while retaining the advantages of dynamic applications.

For this, the invention provides an application program formed of control modules, each control module representing a high level elementary control, which can be identified by its own identifier, possibly containing an identifier of the corresponding service provider, as well as a identifier of its function.

On the other hand, the invention relates to a method of dynamic execution of such an application program comprising a first step of executing control modules stored on the terminal independently and a second step of downloading control modules from from a remote entity. This download can be made at the request of the terminal as a function of the execution of an order by a previous control module. This process can be implemented using an electronic medium such as a smart card, mobile phone, etc. Download can be done using SMS messages to the SIM card of a mobile phone. The invention and the advantages which ensue from it will appear more clearly on reading the following description of an embodiment, given purely by way of nonlimiting example with reference to the appended drawings, in which: FIG. 1 is a diagram which illustrates an application of the control modules according to the invention to produce functionalities at the level of a SIM chip card; and - Figure 2 is a diagram illustrating the flow of a dialogue between a user and a content provider by control modules according to the invention.

The embodiment implements an application program of a mobile telephone terminal which is broken down into autonomous functional modules, called control modules, each producing a specific high level action on the terminal. These modules are assembled and chained in a modular fashion to constitute a complete executable program. The autonomous nature of the modules means that such an application program can be formed by selectively calling the module or modules chosen by a user. Our invention thus allows a user to personalize a service and represents service management according to a decentralized approach. These points will be better understood from the description which follows.

All control modules have a common format consisting of:

- an identification field (ID) (one byte) which uniquely identifies the module, a content provider identification field (one byte) which ensures that a content provider content cannot access an application from another provider,

- an identification of the module type (one byte) which indicates the function of the control module, - a setting for a specified module type; it involves defining a list of data required to implement a certain type of control module. For example, to display on a screen, you need the content of the text to display and the DCS, acronym for "Data coding scheme", defined by the GSM 03.38 standard, and

- an identification field of the next module (one byte), which includes the identification field of the next control module to be processed. Each command module has a type which corresponds to one or a predefined sequence of action (s), making it possible to define the flow of commands for an application. It thus constitutes an autonomous executable entity. The embodiment provides in particular a respective control module for each of the following actions:

- selection of an item (Select Item),

- extraction of an input (Get Input), - display of text (Display Text),

- establishment of a call (Setup Call),

- module link (Link CP),

- insertion of a chain into a memory stack (Push String), - LOCI reading, acronym for "Location Information", defined in GSM standard 11.11 (Read LOCI),

- concatenation to RAM,

- encryption from RAM, - display from RAM, - sending an SMS message (English acronym for "short message service") from the command module,

- sending of SMS messages from RAM,

- sending an SMS message (recipient number in the control module),

- sending of SMS message (recipient number in RAM),

- user profile,

- deletion of the control module (Delete), - distribution (dispatcher),

- tone sending (PlayTone),

- formatting and exchange of half-byte (nibble),

- extraction, and

- value range check, - length range check.

These are therefore high-level elementary commands. To detail a particular example, a "GET INPUT" command could be of the form:

Qualify = 0x04, Min = 5, Max = 15

"What is your name? ".

The invention combines the dynamic mode of the prior art and the modular structure of the invention. This keeps the advantage of having an application program that can benefit from up-to-date data, accessible on a remote server. For this, we use message exchanges in SMS format; the length of a control module is such that each

SMS can contain several modules. To further optimize this management of message exchanges and to fill the space available by SMS as much as possible, it is also possible to provide for the division of a module into two pieces, each located on two separate SMSs. The invention makes it possible to optimize the size of all the data to be transferred and therefore the number of SMS necessary, which solves the problem of the heaviness of the dynamic processing of the prior art.

There are in particular three control modules dedicated to SMS exchanges to manage the dynamic part of the application program.

- A first module called "Delete" which contains as a parameter the value of the identification fields of the modules to be deleted and thus makes it possible to delete specific modules. -A second module called "Update" for updating a control module. To modify a local control module, the supplier sends to the terminals concerned an "Update" modification module bearing the supplier's identifier, the identifier of the module to be updated, and the indication of the new configuration or of the new content. . The update thus obtained is transparent to users. To allow the user to be informed, the SIM card includes a communication module, known as an update indication, which causes the display of a fixed message such as "updated application". This indication module can be triggered by the modification module. As a variant, the update control module can include a variable display field making it possible to specify the change made.

-A third module called "Trigger" which allows to target a certain command module by its identification field in order to start the execution of the program from any module.

FIG. 1 illustrates an application of the control modules according to the invention for producing functionalities for the user at the level of a SIM chip card 2 of a mobile telephone terminal. The SIM smart card 2 includes its own microprocessor 6, a volatile memory of the RAM type 8

("random access memory"), a fixed ROM type memory

10 ("read only memory"), an electrically erasable rewritable memory of the type EEPROM 12

("electrically erasable programmable read only memory"), and a communication interface 14 comprising contact pads for connecting the card 2 functionally to the circuits of the terminal 4. The SIM card 2 communicates via the mobile telephone terminal 4 with suppliers of content, each providing an online service: information, purchase orders, assistance, etc.

To communicate with a content provider 18, the mobile telephone terminal 4 passes through a central station 16, called SMSC, which acts as a relay for the wireless link to the GSM or UMTS protocol. This central station brings together all content providers. The dialogue, ie the transaction, between the mobile telephone terminal 4 and a content provider 18 implies the execution in real time of an application program at the SIM card 2 level, to manage inter alia the data exchanges with the supplier externally and the man-machine interface via the screen 4a and the keyboard 4b internally.

According to the invention, the application programs for dialoguing with the content providers are composed of control modules (MC) described above. In the example shown in FIG. 1, these modules MC are stored in the EEPROM memory portion 12, being elements capable of being modified or deleted in the long term according to the user's application choices. However, some MC control modules can be pre- programmed in the frozen memory ROM 10 if they relate to immutable and fundamental elements, for example the management of a main menu. During processing, MC control modules can also be temporarily transferred to RAM 8.

Naturally, the invention remains compatible with any local or static mode, where the set of control modules MC capable of being used is preloaded in the memory of the SIM card 2 (for example in the EEPROM memory 12). In this case, all the users of the content provider therefore have the same set of modules pre-loaded in the SIM card, either in personalization or in post-personalization. The content provider can nevertheless at any time update its program by SMS message or equivalent (for example to insert a new section in a menu display module), or by message of deletion or selective addition of a existing module and loading a control module.

The management of modules in the memory of the smart card is totally different from that of the prior art: in fact, all the modules of the same application program are combined in the same file structure. This memory management has many advantages of flexibility compared to the prior art. Indeed, the modules are small and loading them into a file presents many possibilities. As long as there is room in the file, it is possible to add modules, which allows the user to build a personalized service by storing in this file the modules of his choice. This personalized construction of the application program can be done in an execution phase of the application program, during which the user progressively downloads the modules which are necessary for him and which are not present in the SIM card 2 and decides or not to keep them locally. For example, a user can choose to locally keep modules that he uses regularly and that are unlikely to change. During a subsequent execution, it will therefore statistically use a large number of modules already present in its card, which will make execution faster.

Some of these possibilities are described by the following example, illustrated in FIG. 2, of a dialogue concerning a transaction between a user of a mobile telephone terminal 4 comprising a SIM card 2 provided for processing compliant command modules to the invention and a content provider offering online ticketing of Parisian cinemas.

The user starts the process by displaying on his screen 4a the main menu MP of the various content providers accessible online. It selects the ticketing provider for Parisian cinemas, which automatically activates a first MCI command module produced by the supplier of this ticketing, which causes the display of a list of Paris arrondissements. This MCI module, as well as all the other modules used within the framework of the transaction, comprises the identifier 24 of the content provider IDFC (0x00 in the example), and its own identifier 26 of the control module (0x01 in the example). The identifier 24 of the content provider is unique for the same provider ; the identifier 26 of the control module MC is unique for this module.

The first MCI control module, like any module intended for producing a message display, is of the type comprising a display command and a data field to be displayed. It is also intended to take note of a command received by the keyboard 4b on the basis of this display.

Often mentioned, the first MCI control module is stored locally in the SIM card 2.

Depending on the district selected

(second) via the keyboard 4b, the control module MCI selects and calls up a second control module

MC2, also stored locally, which produces the display of the list of cinemas in this district. Since the list of cinemas is relatively constant over time, this second module MC2 is also stored locally in the SIM card 2.

Once the cinema (Light) has been selected, the second module MC2 calls a third control module MC3, called a request module, which transmits to the supplier

(cinema ticket office) an SMS request message. This message includes a configurable field allowing to indicate the required data. In this case, the third control module enters the "LIGHT PROG" parameter in the appropriate field, in accordance with the selection recorded by the second MC2 module, to obtain the program for the selected cinema.

In response, the cinema ticket office or the central server sends to the SIM card 2 a control module MC4 containing the data relating to the films of the selected cinema and a command to display this data. This remote module MC4 is activated on reception to display its data on the screen 4b in the form of a list of films. Once the user selects the film (film C), the control module MC4 calls a fifth control module MC5 which is a request module whose configurable field specifies a schedule request for the selected film "HOR.FILM C ", in accordance with the selection saved by the module preceding MC4.

In response, the ticket office or its central server sends to the SIM card 2 a control module MC6 containing the data concerning the screening times for the film C selected and a display command for this data. This remote module MC6 is activated on reception to display this data on the screen 4b in the form of a schedule list for film B.

Once the user selects the schedule

(7:45 p.m.), the MC6 command module calls a seventh MC7 module which is a message formatting module

SMS parameterized by two fields: the name of the film "FILM NAME" and the schedule "TIMETABLE", in order to establish the purchase order for the ticket. These fields are filled in automatically respectively on the basis of the selections recorded on the fourth and sixth modules MC4 and MC6. Then, the seventh module MC7 calls an eighth module MC8 for transmission to the ticket office or from the central server 18 of the formatting result established by the module MC7. On receipt of the MC8 module, the ticket office or the central server extracts the content of two fields "FILM NAME" and "TIMETABLE" from the formatting result in order to reserve a place for film C at the 7:45 pm screening for the user identified by the GSM call.

In the example, all the remote modules are transmitted to the SIM card 2 by SMS messages. Of course, other modules can be implemented in a similar manner to establish various other conditions for the reservation: number of places, date other than the same day, etc. Note from the example the execution in a transparent manner for the user of the static control modules stored in the SIM card 2 and of the dynamic control modules stored with the content provider (ticket office) or, where appropriate, its central server. . The choice of storage of the modules in local or remote mode is arbitrary and depends on considerations of size, available volume in memory in the SIM card 2, frequency of use and update, etc. The generic control modules, in particular for sending an SMS message (MC3, MC5, MC8) or for formatting (MC7) are advantageously stored locally in the SIM card 2.

The identifiers 26 of the control modules are advantageously established dynamically according to their order of use, making it possible to keep in memory a sequence of use of successive modules. The remote modules (for example MC4 and MC6) loaded in the card can remain there after their use to avoid recharging them again if necessary.

However, in order not to clutter the memory space, these remote modules can be erased by internal management of the card. They can also be deleted automatically once their usefulness has ended. Because the control modules according to the invention allow tailor-made applications, it is optional the possibility of keeping in the SIM card 2 a follow-up, accessible remotely by the content provider, of the applications configured on the SIM card 2 and corresponding to the profile of its user.

The invention also allows the advantageous implementation of a bookmark or electronic bookmark (also known by the English term "bookmark"). The bookmark allows the user to store any "proactive" command module, ie by which he can interact with both the link and the data of a telecommunication session. In this way, a specific page can be evoked and presented.

The bookmark is managed by the configuration byte of a control module, by positioning a particular bit of the latter in predetermined logic state. Saving a bookmark is done by registering a shortcut from a menu. The bookmark details are separated into three sections

- properties, i.e. the list of bookmarks and the space available for storing additional bookmarks,

- quick access details, either the name of the bookmark and the link (identification 26 of the control module subject to a bookmark), and - the session data, or the path traveled by an application and the results of the path.

Preferably, only the content provider is able to link to a bookmark. The user will be presented with a list of shortcuts in memory.

A bookmark can be removed by a menu in order to delete the link from the list and thus free up memory space. The invention allows many variations to level of applications, the structure of control modules, the actions they produce, their content, their transport and their internal management. For example, this modular structure can be combined with a conventional structure of web pages so as to form a single service.

Furthermore, the control modules can be stored on any medium and executed on any medium, for example any smart card or other similar object with limited memory, portable computers, computer peripheral, personal digital assistant, etc. They can be applied to different technologies for communication with a remote server, such as GSM as we have seen, but also other wireless communications, or the Internet ...

Furthermore, it is clear that several control modules can be loaded in a grouped manner in the terminal 4 in response to a request from the latter, for example in anticipation of imminent actions to be performed, rather than individually by specific request such as in the example.

Claims

1. A method of execution by a terminal (4) of an application program supplied by a remote entity, characterized in that it comprises the steps of executing a set of control modules stored on the terminal autonomously, and

- download and execute command modules from the remote entity.

2. Method according to claim 1, characterized in that each control module is given:

- a unique identifier,

- an identifier of the remote entity, and - an identifier of its function.

3. Method according to any one of the preceding claims, characterized in that the control modules are stored on the terminal in the same file.

4. Method according to any one of the preceding claims, characterized in that a control module is downloaded at the request of the terminal according to the execution of an order by a previous control module.

5. Method according to any one of the preceding claims, characterized in that the control module comprises display data on the screen (4a) of the terminal (4).

6. Method according to any one of the preceding claims, characterized in that it comprises a bookmark establishment phase, for establish a link within the terminal (4) to at least one control module of the remote entity.

7. Electronic support, characterized in that it contains a means of storage and execution of at least one control module.

8. Electronic support according to the preceding claim, characterized in that it is a smart card.

9. Portable telephone (4) capable of implementing the method according to claims 1 to 6, characterized in that a control module is downloaded to the terminal (4) by a message in SMS format.

10. Portable telephone (4) according to the preceding claim characterized in that it contains at least one control module stored and executed on its SIM chip card.

11. Implementation of the method according to any one of claims 1 to 6 for obtaining a service from a content provider from a mobile telephone terminal (4), comprising the steps of:

- Execute at least one command module within the terminal, taking into account a selection sent by the user of the terminal, and - Send a message to the content provider depending on the execution of said command module.

12. Implementation of the method according to any one of claims 1 to 6 by a content provider to provide a service to a mobile telephone terminal (4), comprising the steps of:

- providing the terminal (4) with at least one control module, and - responding to the terminal according to a message received from the latter in response to the execution of the control module.

13. Application program characterized in that it comprises at least one command module representing a high-level command offered by a service provider.