Telecommunication Terminal Comprising Two Execution Spaces

Abstract

The inventLion relates to a user interface-equppedi computing device comprising mneans for implementing a series of applicatiorm, said means including two execution spaces. According to the invention. the applications of the second execution space (100, P1, 200, P2) have a level of security specifically htigher than that of the applications of the first execution space (100, P1, 200, P2), said two execution spaces beino hosted by a physical processing means which is designed such that it carnnot be separated into two parts without destroying the physical processing means.

Description

Other characteristics, purposes and advantages of the invention will become apparent on reading the following detailed description which refers to the appended figures in which:

FIG. 1 is a schematic illustrating a MIDP implementation of the prior art

FIG. 2 is a schematic illustrating the implementation of protection means in a said MIDP implementation,

FIG. 3 is a schematic illustrating a prior art STIP implementation

FIG. 4 illustrates a functional configuration of an inventive terminal according to a preferred variant-

The particular embodiment described below makes it possible to take best advantage of both techniques, MIDP and STIP, given as an example within a coherent execution environment.

The “user” profile is formed therein, the MIDP profile. This profile is very popular in the world of cell phones for creating games and various utility applications. The user is able to download and execute applications found on the network in the same way as with a usual MIDP telephone. The MIDP profile therefore includes applications set up and activated by the users themselves.

Here the STIP profile forms an additional profile, and more specifically an “operator” profile. The STIP profile is well adapted to applications requiring a high security level, such as banking applications. Banking consortiums have already placed their trust in the possibility using formal methods to certify STIP applications for their implementation in electronic payment terminals (EPT).

With the present invention it is therefore possible to provide developers with an operator API assembly whose execution is ensured in an execution space appropriate for easy programming by these developers, a space of whether or not of same profile, and fully separate.

This embodiment therefore enables operators to provide a batch of securitized applications such as payments, signature or.DRM, that is fully independent from the execution profile for “routinet” applications.

The terminal shown FIG. 4 includes and causes to operate in harmony two virtual machines 100 and 200 of separate profiles Pi and P2 (or not separate). One 100 of the two machines is dedicated to user applications, the other 200 to operator applications.

The corresponding profiles P1 and P2, here respectively the MIDP profile and the STIP profile, are themselves respectively dedicated to user applications and operator applications.

FIG. 4 shows two virtual machines 100 and 200.

The “user” virtual machine 100 can be used by the user to download, install, uninstall, execute, stop applications in the MIDP profile as and when desired. The applications 110 operating therein use the API 120 of this profile and an API “stub” having the same profile as the machine 100, this API stub being referenced 130 in FIG. 4.

The second machine, referenced 200 is the “operator” virtual machine: only the operator e.g. the mobile telephone operator or the internet operator (access supplier), via an over the Air (OTA) mechanism, is able to administrate this execution space.

The operator can, at will, install, uninstall, activate, deactivate therein applications 210 written as per the formalism of profile 100. These applications 210 have access to APIs 220 of profile P2 and to one or more high level APIs illustrated under reference 230 in FIG. 4.

These high level APIs 230 allow access to services offered by the profile of machine 100. API access, whether from the profile of machine 200 or the stub 230 to the profile of machine 100 is made in accordance with the security model inherent in the profile of machine 200.

The API “stub” 130 is a high level API, expressed as per the programming model of profile 100, providing access to services offered by profile P2. API access, whether to the profile of the machine 100 or a stub 130 is made in accordance with the security model inherent in the profile Pi of machine 100.

The functioning of stubs 130 and 230 is as follows:

The call to an API of stub 130, 230 is converted into a flow of octets (called either serialization process or marshalling /unmarshalling).

This flow is received by a manager 140, 240 of the opposite profile via a communication channel 300, deserialized and converted into execution of a procedure in the remote profile. The return execution of this procedure is again serialized in the remote profile and passes again in the communication channel 300 between the two profiles P1 and P2 of machines 100 and 200, the reply is deserialized in the original profile and converted into a return call of the API “stub”.

In this way there are two independent execution spaces each consisting here of a different machine and a different profile, and in very close relationship via the API stub 130 and 230.

As a variant, the two profiles P1 and P2 may be of same type e.g. two MIDP profiles or two STIP profiles for two different machines.

It will also be noted that it is possible to adopt two different profiles P1 and P2 within one same virtual machine.

This embodiment therefore offers a payment API to developers of MIDP applications, in which the payment itself is made under the execution of a virtual STIP machine controlled by the operator.

In other words, a MIDP application, easily developed, could offer the user a means of payment by causing a payment application of machine 200 to operate via the communication channel 300. A MIDP application, through the invention, is therefore able to offer a payment functionality that is highly reliable.

The two execution spaces 100 and 200 each formed of a virtual machine/execution profile pair, differing from one another through the profile or the virtual machine, are both implemented however by one same physical processing device 400 (same hardware entity 400).

This processing device hosting the two execution spaces. is unique in that it cannot be divided into two without destroying its functioning.

It is therefore impossible to physically separate the two execution spaces, and it is hence also impossible to associate a space thus separated with another space which is not authorized.

Said achievement with a single means is obtained for example by implementing the two execution spaces on one same integrated circuit forming a single processor.

It is thereby ensured that two environments, one securitized and the other non-securitized, are inseparable.

The security offered by an operator (telephony, banking, signature administration, multimedia distributor) is thereby improved whether to prevent security overriding in payment functions, to ensure confidentiality or non-usurpation of secret codes, to ensure reliability of electronic signatures or to monitor limited user rights for payable services.

Advantageously the Pi, P2 profiles of each of the two execution spaces 100, P1, 200, P2 are respectively a STIP profile and a profile forming part of the group made up of STIP, MIDP, OSGI and “.net” profiles.

Claims

1. Computing device with user interface comprising means for implementing a series of applications, these means including in particular a virtual machine/functioning profile execution space (100, P1, 200, P2), the device comprising a second virtual machine/functioning profile execution space (100, PI, 200, P2) differing from the first by at least its virtual machine (100, 200) or its functioning profile (Pl,P2), each execution space hosting applications (110, 120, 130, 140, 220, 230), the applications of the second execution space (100, P1, 200, P2) being applications with a specifically higher level of security than the applications of the firet execution space (100, P1, 200, P2) since the applications (110, 120, 130, 210, 220, 230) of the first execution space (100, P1, 200, P2) are applications which can be modified by the user, whilst the applications (110, 120, 130, 210, 220, 230) of the second execution space (100, PI, 200, P2) are applications which cannot be modified by the user, characterized in that the two execution spaces are hosted by one same physical processing means (400) which is arranged so that it cannot be separated into two parts without destroying this physical processing means (400).

2. Device as in claim 1, characterized in that the applications (110, 120, 130, 210, 220, 230) of the second execution space (100, PI, 200, P2) are applications which can be modified by a security operator belonging to the group consisting of telephony operators, banks, providers of multimedia items with selective or paying distribution, service providers operating against electronic signature via said device.

3. Device as in claim 1 or claim 2, characterized in that it forms a telephone terminal.

4. Device as in claim 3, characterized in that it forms a mobile telephony terminal.

5. Device as in any of the preceding claims, characterized in that it comprises communication means (130, 230, 300) between the two execution spaces (100, P1, 200, P2).

6. Device as in claim 5, characterized in that the communication means (130, 230, 300) between the two execution spaces are designed to authorize an application (130, 230) of one of the two execution spaces to have recourse to processing means of the second execution space (100, P1, 200, P2).

7. Device as in any of the preceding claims, characterized in that each of the two execution spaces includes at least one separate API (120, 130, 220, 230).

8. Device as in any of the preceding claims, characterized in that the communication means include an API “stub” (130, 230) whose role is to have recourse to resources of the opposite execution space (100, P1, 200, P2), these resources implementing a selection regarding access to them in relation to the caller application (110, 210).

9. Device as in any of the preceding claims, characterized in that the communication means between the two execution spaces (100, P1, 200, P2) include means implementing serialization/deserialization or marshalling/unmarshalling.

10. Device as in any of the preceding claims, characterized in that one of the two execution spaces (100, PI, 200, P2) includes a profile of STIP type.

11. Device as in any of the preceding claims, characterized in that one of the two execution spaces (100, PI, 200, P2) includes a MIDP profile.

12. Device as in any of the preceding claims, characterized in that the profiles (Pl,P2) of each of the two execution spaces (100, P1, 200, P2) are respectively a STIP profile and a profile forming part of the group consisting of STIP, MIDP, OSGI and “.net” profiles.

13. Method for implementing applications within a computing device with user interface, the method having recourse to means for implementing a series of applications, these means particularly including a virtual machine /functioning profile execution space (100, P1, 200, P2), and a second virtual machine/functioning profile execution space (100, P1, 200, P2) differing from the first by at least its virtual machine (100, 200) or its functioning profile (P1,P2), each execution space (100, PI, 200, P2) hosting applications, the applications of the second execution space (100, P1, 200, P2) being applications with a specifically higher level of security than the applications of the first execution space (100, PI, 200, P2) since the applications (110, 120, 130, 210, 220, 230) of the first execution space (100, PI, 200, P2) are applications which can be modified by the user, whilst the applications (110, 120, 130, 210, 220, 230) of the second execution space (100, PI, 200, P2) are applications which cannot be modified by the user, characterized in that the two execution spaces are hosted by one same physical processing means (400) which is arranged so that it cannot be separated into two parts without destroying this physical processing means (400).