Patent Description:
This section is intended to introduce the reader to various aspects of art, which may be related to various aspects of the present invention that are described and/or claimed below. This discussion is believed to be helpful in providing the reader with background information to facilitate a better understanding of the various aspects of the present invention.

Java Card technology is widely used in smart cards and similar trusted devices with limited memory and processing capabilities, such as smart buttons, universal serial bus (hereinafter "USB") tokens, and the like.

<FIG> illustrates an exemplary architecture of a typical Java Card device <NUM>. The Java Card device <NUM> includes a smart card platform (hereinafter "SCP") <NUM>, a Java card system (hereinafter "JCS") <NUM> running on top of the SCP <NUM>, and one or more Java Card applets <NUM> running on top of the JCS <NUM>.

The SCP <NUM> is a combination of a security integrated circuit (hereinafter "IC") <NUM> and an operating system (hereinafter "OS") <NUM>. The IC includes processing units, security components, input/output (hereinafter "I/O") ports and three kinds of memories: a read-only memory (hereinafter "ROM"), a persistent mutable memory such as an electrically erasable, programmable read only memory (hereinafter "EEPROM") or a flash memory, and a volatile memory such as a random-access memory (hereinafter "RAM"). The RAM can be used to store fields of transient objects. Typically, RAM technology has a much faster write cycle time than the EEPROM.

The JCS <NUM> implements a Java Card runtime environment (hereinafter "JCRE"). According to the Java Card Platform Runtime Environment Specification, Classic Edition Version <NUM> (hereinafter "JCCRE"), the JCRE includes a Java Card virtual machine (hereinafter "JCVM"), Java Card Application Programming interface (hereinafter "API") classes (including core packages and/or industry-specific extension packages), and support services. The JCS <NUM> provides a layer between the SCP <NUM> and the Java Card Applet(s) <NUM>. This layer allows the Java Card Applet(s) <NUM> written for one SCP <NUM> enabled with the Java Card technology to run on any other SCP <NUM> enabled with the Java Card technology.

A JCVM thread is a Java object and a basic unit of processor utilization. According to the JCCRE, the JCVM can support only a single thread of execution, meaning that only one command can be processed by the processing unit of the Java Card device <NUM> at any time.

A stack is a linear data structure, meaning that its data elements are organized into a sequence, as is well known to the skilled person. In addition, insertion and deletion of data elements can only be done from one end of a stack. Insertion of the data elements is called push, and deletion of the data elements is called pop. The order according to which the data elements are inserted into or removed from the stack may be last-in, first-out, meaning that the first data element pushed onto the stack is the last data element popped off the stack. A stack could be implemented through an array, a vector, an ArrayList, a linked list, or any other linear collection of data elements.

A JCVM stack is allocated to each JCVM thread by the JCVM. The JCVM stack is created in the RAM by the JCVM at the same time as the JCVM thread. The data elements stored in the JCVM stack are JCVM frames. A JCVM frame is created each time a method is invoked by the JCVM thread, is used to store local variables and has an operand stack, which is well known to the skilled person.

Compared with the size of the ROM (e.g., <NUM>-<NUM> kilobytes) or the non-volatile memory (EEPROM or flash, e.g., <NUM> kilobytes) of the Java Card device <NUM>, the size of the RAM is by nature very limited (e.g., <NUM> kilobytes). Hence the RAM is the most precious resource on the Java Card device <NUM> from a card software developer's point of view.

However, volatile memory management in existing Java Card devices is not satisfactory and reducing volatile memory usage of Java Card devices is a desirable aim. In particular, there is a need to improve the management of memory space allocation in the volatile memory of a Java Card device (such as the Java Card device <NUM> illustrated by <FIG>) running one or more Java Card applets, in order to optimize RAM use and improve global performances of the Java Card device.

The European patent application no. <CIT> discloses a security module and method for optimum memory utilization. Said security module comprises: a dynamic storage device including a first storage area storing one or more native codes and a second storage area storing one or more Java packages, and a processor being operationally coupled to the dynamic storage device configured to: detect presence of the one or more native codes in the first storage area, form the detected one or more native codes in the first storage area as a part of the second storage area, and manage the one or more native codes like the Java packages in the second storage area.

The present invention is as defined by the appended claims.

In a first aspect of the invention, a particular embodiment provides a Java Card device. The Java Card device comprises a volatile memory, an OS, and a JCVM. The JCVM comprises a JCVM thread. The volatile memory comprises a first portion, a second portion within the first portion, and a third portion outside the first portion. The first portion is allocated to an OS stack for supporting execution of native code defined in a language used for programming the OS. The second portion is allocated to a JCVM stack for supporting the JCVM thread. The third portion is allocated to a heap.

According to the particular embodiment of the first aspect, the first portion of the volatile memory may be shared between data elements of both the JCVM stack and the OS stack, without the heap separating the two stacks, meaning that the data elements of the OS stack may make use of all memory spaces of the first portion which are not occupied by any data element of the JCVM stack, and vice versa, hence increasing the maximum number of data elements that can be stored in each of the OS stack and the JCVM stack without additional memory areas being allocated to the OS stack or to the JCVM stack. As such, the Java Card device according to the embodiment of the invention may utilize the volatile memory more efficiently.

In a particular embodiment of the first aspect, the volatile memory further comprises a fourth portion outside the third portion and outside the first portion. The fourth portion is allocated to an initialized segment for storing global variables and/or static local variables.

In a particular embodiment of the first aspect, the third portion is positioned within the volatile memory between the first portion and the fourth portion.

In a particular embodiment of the first aspect, the first portion is configured to store the whole OS stack and the whole JCVM stack. A size of the first portion is smaller than a sum of first maximum memory consumption of the OS stack and second maximum memory consumption of the JCVM stack. The first maximum memory consumption of the OS stack is maximum memory consumed by data elements of the OS stack within the volatile memory during execution of the native code. The second maximum memory consumption of the JCVM stack is maximum memory consumed by data elements of the JCVM stack within the volatile memory when the JCVM thread runs.

In a particular embodiment of the first aspect, addresses occupied by data elements in the JCVM stack are configured to grow from a start address of the JCVM stack towards a start address of the OS stack, as the number of the data elements in the JCVM stack increases. Addresses occupied by data elements in the OS stack are configured to grow from the start address of the OS stack towards the start address of the JCVM stack, as the number of the data elements in the OS stack increases.

In a particular embodiment of the first aspect, a location, relative to one end of the first portion, of a boundary between one data element of the JCVM stack and one adjacent data element of the OS stack is configured to vary dynamically as the number of data elements in the JCVM stack and the number of data elements in the OS stack vary.

In a particular embodiment of the first aspect, the first portion and the JCVM stack share a same start address or share a same end address.

In a particular embodiment of the first aspect, a size of the first portion equals a sum of a size of a buffer and third maximum memory consumption. The third maximum memory consumption is cumulated maximum memory consumed by data elements of both the JCVM stack and the OS stack within the volatile memory at one moment.

According to the various embodiments of the present invention, the Java Card device may be (or comprise) a smart card, a terminal, or any other equivalent device with various formats (e.g., a USB key).

In a second aspect of the invention, a particular embodiment provides a method for managing a volatile memory. The method comprises: allocating a first portion of the volatile memory to an OS stack for supporting execution of native code defined in a language used for programming an OS; allocating a second portion of the volatile memory, within the first portion, to a JCVM stack for supporting the JCVM thread; and allocating a third portion of the volatile memory, outside the first portion, to a heap.

In a particular embodiment of the second aspect, the method further comprises: assessing third maximum memory consumption of the JCVM stack and the OS stack; and determining a size of the first portion by adding a size of a buffer to the third maximum memory consumption. The third maximum memory consumption is cumulated maximum memory consumed by data elements of both the JCVM stack and the OS stack within the volatile memory at one moment. The size of the buffer is greater than <NUM>.

In a particular embodiment of the second aspect, allocating the first portion to the OS stack comprises: determining a start address of the OS stack according to a specified first value; and/or, determining an end address of the OS stack according to a specified second value. One of the start and end addresses of the OS stack equal to one of a start address of and an end address of the first portion.

In a particular embodiment of the second aspect, allocating the second portion to the JCVM stack comprises: determining a start address of the JCVM stack according to a specified third value; and/or, determining an end address of the JCVM stack according to a specified fourth value. One of the start and end addresses of the JCVM stack equal to one of a start address of and an end address of the first portion.

In a particular embodiment of the second aspect, allocating the third portion to the heap comprises: determining a start address of the third portion according to a sum of a start address of the fourth portion and a size of the fourth portion.

In a particular embodiment of the second aspect, allocating the third portion to the heap comprises: determining an end address of the third portion according to a start address of the first portion.

In a particular embodiment of the second aspect, the size of the fourth portion is determined according to sizes of the global variables and/or static local variables stored in the initialized segment.

In a particular embodiment of the second aspect, the first portion is configured to store the whole OS stack and the whole JCVM stack, and the method further comprises: determining a size of the first portion to be smaller than a sum of first maximum memory consumption of the OS stack and second maximum memory consumption of the JCVM stack. The first maximum memory consumption of the OS stack is maximum memory consumed by data elements of the OS stack within the volatile memory during execution of the native code. The second maximum memory consumption of the JCVM stack is maximum memory consumed by data elements of the JCVM stack within the volatile memory when the JCVM thread runs.

In a particular embodiment of the second aspect, the method further comprises: configuring addresses occupied by data elements in the JCVM stack to grow from a start address of the JCVM stack towards a start address of the OS stack, as the number of the data elements in the JCVM stack increases; and configuring addresses occupied by data elements in the OS stack to grow from the start address of the OS stack towards the start address of the JCVM stack, as the number of the data elements in the OS stack increases.

In a particular embodiment of the second aspect, the method further comprises: configuring a location, relative to one end of the first portion, of a boundary between one data element of the JCVM stack and one adjacent data element of the OS stack to vary dynamically as the number of data elements in the JCVM stack and the number of data elements in the OS stack vary.

The method according to the various embodiments of the second aspect may be performed by a device or system for managing the volatile memory. For example, the method may be performed by the Java Card device according to the first aspect, and/or, by one or more devices independent of said Java Card device.

According to a particular embodiment of the invention, for each step (or operation) of the method as defined in the second aspect of the present invention, the device or system for managing the volatile memory may comprise a corresponding module configured to perform said step.

Where functional modules are referred to in the present invention for carrying out various steps (or operations) of the described method(s), it will be understood that these modules may be implemented in hardware, in software, or a combination of the two. When implemented in hardware, the modules may be implemented as one or more hardware modules, such as one or more application specific integrated circuits. When implemented in software, the modules may be implemented as one or more computer programs that are executed on one or more processors.

Accordingly, the invention also provides one or more computer programs on one or more recording media. The one or more computer programs are arranged to be implemented by a device or system (such as the device or system for managing the volatile memory, which is described above), and more generally by one or more processors. The one or more computer programs comprise instructions adapted for the implementation of the method for managing the volatile memory as defined by the second aspect of the present invention.

The computer programs of the invention can be expressed in any programming language, and can be in the form of source code, object code, or any intermediary code between source code and object code, such that in a partially-compiled form, for instance, or in any other appropriate form.

Additionally, it is noted that the program(s) of instructions to implement the present invention could be stored on a number of computer-readable memory devices and storage media. For example, during actual execution, the program instructions would reside in a RAM memory device. When not being actually executed, the program instructions would reside in memory such as a ROM memory device, so as to be selectively executable. Alternatively, the program instructions might be remotely stored on a memory device of a server available through a network, or might be stored in a standalone storage device such as an optical disk or other suitable non-transitory memory device capable of tangibly embodying a program of machine-readable instructions and suitable for insertion into an input device on a computer, for loading the machine-readable instructions onto a memory device within the computer, as is well known in the art.

The invention also provides a recording medium readable by a device, or more generally by a processor, this recording medium comprising computer program instructions as mentioned above.

In addition, the recording medium can be any entity or device capable of storing the computer program. For example, the recording medium can comprise a storing means, such as a ROM memory (a CD-ROM or a ROM implemented in a microelectronic circuit), or a magnetic storing means such as a floppy disk or a hard disk for instance.

Moreover, each recording medium previously mentioned can correspond to a transmittable medium, such as an electrical or an optical signal, which can be conveyed via an electric or an optic cable, or by radio or any other appropriate means. The computer program according to the invention can in particular be downloaded from the Internet or a network of the like.

Alternatively, the recording medium can correspond to an integrated circuit in which a computer program is loaded, the circuit being adapted to execute or to be used in the execution of the methods of the invention.

The various embodiments defined above in connection with the method of the second aspect of present invention may apply in an analogous manner to the Java Card device, the device or system for managing the volatile memory, the computer program and the non-transitory computer readable medium of the present invention.

Certain aspects commensurate in scope with the disclosed embodiments are set forth below. It should be understood that these aspects are presented merely to provide the reader with a brief summary of certain forms the invention might take and that these aspects are not intended to limit the scope of the invention. Indeed, the invention may encompass a variety of aspects that may not be set forth below.

Particular embodiments of the invention and advantages thereof will be described below in detail, by way of example, with reference to the accompanying drawings on which:.

In <FIG>, the represented blocks are purely functional entities, which do not necessarily correspond to physically separate entities. Namely, they may be developed in the form of software, hardware, or be implemented in one or several integrated circuits, comprising one or more processors.

For simplicity and clarity of illustration, the same reference numerals will be used throughout the figures to refer to the same or like parts, unless indicated otherwise.

The following description of the exemplary embodiments refers to the accompanying drawings. The following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims. In various embodiments as illustrated in the figures, a method for managing a volatile memory and a Java Card device (also named Java Card technology-based device) are described.

It is to be understood that the figures and descriptions of the present invention have been simplified to illustrate elements that are relevant for a clear understanding of the present invention, while eliminating, for purposes of clarity, many other elements found in typical Java Card devices and memory management methods.

The flowcharts and/or block diagrams in the figures illustrate the configuration, operations and functionality of possible implementations of devices, method and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s).

The term "address" herein may be understood as virtual address. The virtual addresses are provided by an OS kernel (core part of the OS which is responsible, for example, to manage hardware components such as a memory).

The term "may" hereinafter indicates possible implementations of embodiments of the invention. Features characterized by said term and features covered by other implementations and/or by other examples can be implemented independently of each other or in combination, unless otherwise specified.

As depicted in <FIG>, a Java Card device <NUM> according to a first embodiment of the present invention includes a volatile memory <NUM>, an operating system (hereinafter "OS") <NUM>, and a Java Card virtual machine (hereinafter "JCVM") <NUM>. The JCVM <NUM> comprises a JCVM thread <NUM>, that is, a basic unit of Java Card applet execution as specified by the JCCRE.

The volatile memory <NUM> may be a static RAM, dynamic RAM, or any other kind of volatile memory.

The OS block <NUM> shown in <FIG> and the OS block <NUM> shown in <FIG> may represent the same operating system or different operating systems.

The OS <NUM> may be any OS compatible with the Java Card technology, such as Windows, Linux or macOS. The OS <NUM> may be programmed or defined in any programming language suitable for programming the OS, e.g., any one or any combination of C, C++, python, an assembly language, and etc..

As illustrated by <FIG>, the Java Card device <NUM> may comprise a ROM <NUM>. The OS <NUM> and the JCVM <NUM> may be stored in the ROM <NUM>. The Java Card device <NUM> may further comprise a processor <NUM> connected with the ROM <NUM> and with the volatile memory <NUM>. The processor <NUM> may be configured to execute the OS <NUM> and the JCVM <NUM>. As an example, the processor <NUM> may be a central processing unit (hereinafter "CPU").

As illustrated by <FIG>, the volatile memory <NUM> comprises in this example a first portion <NUM>, a second portion <NUM> within the first portion <NUM>, and a third portion <NUM> outside the first portion <NUM>.

The size of the second portion <NUM> may be equal to or smaller than the size of the first portion <NUM>.

The term "portion" herein refers to a memory portion or memory area, being continuous at least in the virtual address space. That is, a portion of the volatile memory <NUM> herein is formed by one or more memory chunks having consecutive addresses.

The first portion <NUM> is allocated to an OS stack <NUM>. The OS stack <NUM> supports execution of native code. The native code may be executed by the processor <NUM>.

Said native code whose execution is supported by the OS stack <NUM>, is defined in a language used for programming the OS <NUM>, meaning that instead of being compiled to bytecode, said native code is compiled to the native instruction set that is to be executed directly by the processor <NUM>.

Said native code whose execution is supported by the OS stack <NUM> may be any kind of native code comprised in the Java Card device <NUM>. For example, said native code may include any one or combination of: native program(s) comprised in the OS <NUM> (that is, part of the OS <NUM> or the OS <NUM> itself); native applications that can be used from outside the Java Card device <NUM> in the same way as a Java Card applet; and native libraries used by one or more of the native applications, or used to implement/support one or more Java Card APIs (e.g. cryptographic libraries).

Since the Java Card device <NUM> can be accessed through application protocol data units (hereinafter "APDUs"), functionalities of the native programs comprised in the OS <NUM> can also be accessed through APDUs. But the native program(s) comprised in the OS <NUM> does not expose any APIs/methods which can be used by any external application (i.e. outside of the Java Card device <NUM>).

The native applications may run on top of the OS <NUM>. The native applications may reside in parallel to the Java Card system (hereinafter "JCS") of the Java Card device <NUM>. One or more of the native applications may implement, or be used by, the JCS of the Java Card device <NUM>. The JCS of the Java Card device <NUM> may be the same as the JCS <NUM> illustrated by <FIG>. Examples of the native applications include a wireless internet browser (hereinafter "WIB") and an over the air (hereinafter "OTA") application.

The native libraries cannot be used from the outside of the Java Card device <NUM> directly. Like the native programs, the native libraries do not expose any APIs/methods which can be used by any external application outside of the Java Card device <NUM>. The native libraries may be used by the JCS of the Java Card device <NUM> to implement the one or more Java Card APIs. The native libraries may include native libraries comprised in the OS <NUM> (e.g., memory management library or cryptographic engines), and/or, may include native libraries which are not part of the OS <NUM> (e.g., native libraries running on top of the OS <NUM>). The one or more Java Card APIs may be stored in the ROM <NUM>.

The OS stack <NUM> may be used to store local variables, temporary variables and/or return addresses of a native thread or native process for executing said native code, depending on the language used for defining said native code.

The second portion <NUM> within the first portion <NUM> is allocated to a JCVM stack <NUM>. The JCVM stack <NUM> supports the JCVM thread <NUM>.

The OS stack <NUM> and the JCVM stack <NUM> are stacks as defined in the background section. All data elements of both the OS stack <NUM> and the JCVM stack <NUM> occupy different memory areas of the first portion <NUM>.

The first portion <NUM> may be shared between data elements of both the OS stack <NUM> and the JCVM stack <NUM>. Then the data elements of the OS stack <NUM> may utilize any memory space within the first portion <NUM> which is not occupied by the data elements of the JCVM stack <NUM>. Herein a data element of or in the OS stack <NUM>, or, a data element of or in the JCVM stack <NUM>, refers to a data element (such as a frame) pushed into the corresponding stack, e.g., when a method is invoked by the native code or by the JCVM thread <NUM>.

The third portion <NUM> is allocated to a heap <NUM>. The third portion <NUM> does not overlap the first portion <NUM> (so it is distinct from the second portion <NUM> and the first potion <NUM>). The third portion <NUM>, e.g., may be adjacent to the first portion <NUM>, in the virtual address space.

The whole heap <NUM> may be stored in the third portion <NUM>. The heap <NUM> may be a RAM heap.

Data elements of the heap <NUM>, the OS stack <NUM> and the JCVM stack <NUM> occupy different virtual memory areas of the volatile memory <NUM>.

A heap is a hierarchy data structure, a binary tree which satisfies the heap ordering property, which is well known to those skilled in the art. The heap <NUM> may be a JCVM heap, configured to be a common pool of free memory in the volatile memory <NUM> usable by the JCVM <NUM> for dynamic memory allocation. In this common pool of free memory, blocks of memory may be allocated in an arbitrary order for Java class instances and arrays, e.g., CLEAR_ON_RESET and CLEAR_ON_DESELECT objects.

As such, according to the first embodiment of the present invention, the first portion <NUM> of the volatile memory <NUM> may be shared between data elements of the JCVM stack <NUM> and the OS stack <NUM> without the heap <NUM> separating the two stacks <NUM> and <NUM>, meaning that data elements of the OS stack <NUM> may make use of any memory area of the first portion <NUM> which is not occupied by any data elements of the JCVM stack <NUM>, and vice versa, hence increasing the maximum number of data elements that can be stored in each of the OS stack <NUM> and the JCVM stack <NUM> without allocating additional memory areas to the OS stack <NUM> or to the JCVM stack <NUM>. This particular volatile memory layout of the Java Card device <NUM> according to the first embodiment of the invention thus allows improving usage of the volatile memory. Moreover, since the cost of an RAM chip is directly proportional to the available storage memory space of the chip, the Java Card device <NUM> according to the first embodiment of the invention also helps to reduce cost of production as low-cost RAM chips may be used to manufacture the Java Card device <NUM>.

As illustrated by <FIG>, the OS stack <NUM> has a start address referred to as a first start address <NUM>, and the JCVM stack <NUM> has a start address referred to as a second start address <NUM>.

In order to facilitate efficient usage of the volatile memory, the addresses occupied by data elements in the JCVM stack <NUM> may grow from the second start address <NUM> towards the first start address <NUM>, as the number of data elements stored in the JCVM stack <NUM> grows. Additionally, the addresses occupied by data elements in the OS stack <NUM> may grow from the first start address <NUM> towards the second start address <NUM>, as the number of data elements of the OS stack <NUM> increases. For example, as illustrated by <FIG>, the addresses occupied by data elements in the JCVM stack <NUM> may grow from the lowest address to higher addresses within the first portion <NUM>, and the addresses occupied by data elements in the OS stack <NUM> may grow from the highest address to lower addresses within the first portion <NUM>.

In a particular example, the number of data elements of both the JCVM stack <NUM> and the OS stack <NUM> may increase or decrease together. In another particular example, the number of data elements of one of these two stacks <NUM> and <NUM> may increase while the number of data elements of the other decreases.

The whole OS stack <NUM> and the whole JCVM stack <NUM> may be stored in the first portion <NUM> of the volatile memory <NUM>.

The whole JCVM stack <NUM> may be stored in the second portion <NUM> of the volatile memory <NUM>.

The JCVM stack <NUM> and the OS stack <NUM> may only have one boundary between them when one data element of the JCVM stack <NUM> is adjacent to one data element of the OS stack <NUM>, that is, with no gap therebetween, in the virtual address space. Or, both stacks <NUM> and <NUM> may have two boundaries between them in the virtual address space, when none of the data elements of the JCVM stack <NUM> is adjacent to any data element of the OS stack <NUM>, where the two boundaries may delimit a memory area within the first portion <NUM> which is not occupied by any data element of either the JCVM stack <NUM> or the OS stack <NUM>.

In a particular example, the boundary or boundaries between the JCVM stack <NUM> and the OS stack <NUM> are not fixed. That is, when the two stacks <NUM> and <NUM> have only one boundary therebetween, the location of the boundary between the JCVM stack <NUM> and the OS stack <NUM> varies dynamically as the number of data elements in the JCVM stack <NUM> and the number of data elements in the OS stack <NUM> vary. Alternatively or additionally, when the two stacks <NUM> and <NUM> have two boundaries therebetween, the location of one of the two boundaries varies dynamically as the number of data elements in the JCVM stack <NUM> varies, and/or, the location of the other one of the two boundaries varies dynamically as the number of data elements in the OS stack <NUM> varies. Herein the location of a boundary between the two stacks refers to a location relative to one end of the first portion <NUM>. In this way, the JCVM stack <NUM> and the OS stack <NUM> may make efficient use of the volatile memory.

Herein each portion of the volatile memory <NUM> (e.g., the first portion <NUM>, the second portion <NUM>, the third portion <NUM> and the fourth portion <NUM> illustrated by <FIG>) has a start address and an end address. Herein the start address of a portion refers to the lowest address within the portion, and the end address of the portion refers to the highest address within the portion, although other implementations are also possible.

In a particular example, as illustrated by <FIG>, to make more efficient use of the volatile memory <NUM> and to facilitate the allocation of the second portion <NUM> to the JCVM stack <NUM> at the operation S502 (as described further below), the start address of the first portion <NUM> may be the same as the start address of the JCVM stack <NUM>, when addresses occupied by data elements in the JCVM stack <NUM> grow from the lowest address of the first portion <NUM> to higher addresses within the first portion <NUM>.

In another example, to make more efficient use of the volatile memory <NUM> and to facilitate the allocation of the second portion <NUM> to the JCVM stack <NUM> at the operation S502 (as described further below), the end address of the first portion <NUM> may be the same as the start address of the JCVM stack <NUM>, when addresses occupied by data elements in the JCVM stack <NUM> grow from the highest address of the first portion <NUM> to lower addresses within the first portion <NUM>.

In a particular example, as illustrated by <FIG>, to make more efficient use of the volatile memory <NUM>, the end address of the first portion <NUM> may be the same as the start address of the OS stack <NUM>, when addresses occupied by data elements in the OS stack <NUM> grow from the highest address of the first portion <NUM> to lower addresses within the first portion <NUM>.

In another example, to make more efficient use of the volatile memory <NUM>, the start address of the first portion <NUM> may be the same as the start address of the OS stack <NUM>, when addresses occupied by data elements in the OS stack <NUM> grow from the lowest address of the first portion <NUM> to higher addresses within the first portion <NUM>.

To reduce the memory consumed by data elements of the JCVM stack <NUM>, the JCVM stack <NUM> may be implemented by using an array. In a particular example, the JCVM stack <NUM> may be configured as a Uint16Array typed array. The Uint16Aarray typed array is a built-in object of the JavaScript, well known to the skilled person. Similarly, the OS stack <NUM> may be implemented by using an array as well. Other implementations are, however, possible.

It should be understood that memory consumption of data elements of both the JCVM stack <NUM> and the OS stack <NUM>, i.e. the respective memory areas occupied by the data elements of these stacks within the volatile memory <NUM>, may vary over time depending on various factors. It is considered in a particular example that the OS stack <NUM> reaches its first maximum memory consumption, C1max, when a maximum amount of memory is consumed by the data elements of the OS stack <NUM> within the volatile memory <NUM> during execution of the native code which is supported by the OS stack <NUM>. Similarly, the JCVM stack <NUM> reaches its second maximum memory consumption, C2max, when a maximum amount of memory is consumed by the data elements of the JCVM stack <NUM> within the volatile memory <NUM> during the execution of the JCVM thread <NUM>.

According to a first approach, the size of the JCVM stack <NUM> may be set as C2max and the size of the OS stack <NUM> may be set as C1max. Yet during complete feature testing of various Java Card devices, the Applicant has observed that in practice, the amount of volatile memory consumed by data elements of the OS stack <NUM> and the amount of volatile memory consumed by data elements of the JCVM stack <NUM> never reach their respective maximums concurrently. In other words, whenever the OS stack <NUM> reaches its maximum memory consumption C1max, the memory consumption of the JCVM stack <NUM> is always less (or even significantly less) than its maximum C2max, and vice versa. Accordingly, according to a second approach, which is an implementation of the first embodiment of the invention, when the first portion <NUM> stores the whole OS stack <NUM> and the whole JCVM stack <NUM>, the size of the first portion <NUM> of the volatile memory <NUM> may be set to be smaller than the sum of the first maximum memory consumption, C1max, of the OS stack <NUM> and the second maximum memory consumption, C2max, of the JCVM stack <NUM>. As such, compared with the first approach where the amount of volatile memory reserved for both the OS stack <NUM> and the JCVM stack <NUM> equals to the sum of C1max and C2max, in the second approach the amount of volatile memory reserved for both the stacks <NUM> and <NUM> becomes smaller, thereby further optimizing volatile memory usage.

According to an implementation of the first embodiment as illustrated by <FIG>, the volatile memory <NUM> may further comprise a fourth portion <NUM>, which does not overlap the first portion <NUM> or the third portion <NUM> of the volatile memory <NUM> (so it is distinct from the first portion <NUM> and the third portion <NUM>). The fourth portion <NUM> of the volatile memory <NUM> is allocated to an initialized segment <NUM>. The initialized segment <NUM> may store initialized and/or uninitialized global variables. Since global variables are not allowed in Java, as is well known in the art, said global variables stored in the initialized segment <NUM> may be global variables of any native code of the Java Card device <NUM>, such as the native code whose execution is supported by the OS stack <NUM>.

Additionally or alternatively, the initialized segment <NUM> may store static local variables. Since static local variables are not allowed in Java, either, as is well known in the art, said static local variables stored in the initialized segment <NUM> may be static local variables of any native code of the Java Card device <NUM>, such as the native code whose global variables are stored in the initialized segment <NUM>, or the native code whose execution is supported by the OS stack <NUM>.

As illustrated by <FIG>, the third portion <NUM> may be positioned between the fourth portion <NUM> and the first portion <NUM>, in the virtual address space.

As the number of data elements stored in the initialized segment <NUM> increases, addresses occupied by the data elements in the initialized segment <NUM> may grow from the lowest or the highest address of the fourth portion <NUM>, depending on the specification of the programming language in which the OS <NUM> is programmed. In a particular example, addresses occupied by the data elements in the initialized segment <NUM> may grow in the same direction as those occupied by data elements in the JCVM stack <NUM>. Herein the data elements stored in the initialized segment <NUM> refer to the global variables and/or the static local variables described above.

The whole initialized segment <NUM> may be stored in the fourth portion <NUM> of the volatile memory <NUM>.

The start address of the fourth portion <NUM> of the volatile memory <NUM> may be the lowest address of the volatile memory <NUM>. Or, the end address of the fourth portion <NUM> may be the highest address of the volatile memory <NUM>.

The end address of the first portion <NUM> of the volatile memory <NUM> may be the highest address of the volatile memory <NUM>. Or, the start address of the first portion <NUM> may be the lowest address of the volatile memory <NUM>.

In an example, as illustrated by <FIG>, the third portion <NUM> may start immediately after the fourth portion <NUM> ends in the virtual address space. The start address of the heap <NUM> may immediately follow the end address of the initialized segment <NUM>, or a gap may exist between the start address of the heap <NUM> and the end address of the initialized segment <NUM>.

The OS stack <NUM> may be filled with one or more data elements at run-time of the native code whose execution is supported by the OS stack <NUM>. The JCVM stack <NUM> may be filled with one or more data elements at run-time of the JCVM thread <NUM>. The initialized segment <NUM> may be filled with one or more data elements at link-time (during the compilation process which include compiling and linking) of any native code whose global variables and/or static local variables are stored in the initialized segment <NUM>. The heap <NUM> may be filled with one or more data elements at run-time of the JCVM <NUM>.

The Java Card device <NUM> according to the first embodiment of the disclosure may be a smart card or a similar trusted device with limited memory and processing capabilities, such as a smart button or a USB token. The Java Card device <NUM> may be contact and/or contactless. If it is contactless, it may include a transceiver. For example, the Java Card device <NUM> may include a miniature radio transceiver and an antenna.

As illustrated by <FIG>, a second embodiment of the invention provides a method for managing a volatile memory. According to an implementation of the second embodiment, the method may be implemented by a device for or a system including a plurality of devices for managing the volatile memory. The device or system for managing the volatile memory may include the Java Card device <NUM> as previously described with reference to any one of the <FIG> or a part thereof (such as the processor <NUM>), and/or, may include one or more devices independent of the Java Card device <NUM>. The volatile memory managed by the method according to the second embodiment may be the volatile memory <NUM> as previously described with reference to any one of the <FIG>. The various implementations of the first embodiment defined above in connection with the Java Card device <NUM> may apply in an analogous manner to the method according to the second embodiment of the invention.

More specifically, according to another implementation of the second embodiment, the device or system for managing the volatile memory may implement the method by executing a computer program. The method comprises operations S501- S503 as described further below.

At the operation S501, a first portion <NUM> of the volatile memory <NUM> is allocated to an OS stack <NUM>. The OS stack <NUM> supports execution of native code defined in a language used for programming an OS <NUM>.

At the operation S502, a second portion <NUM> of the volatile memory <NUM>, within the first portion <NUM>, is allocated to a JCVM stack <NUM> for supporting the JCVM thread <NUM>. In other words, the OS stack <NUM> and the JCVM stack <NUM> share the first portion <NUM>.

At the operation <NUM>, a third portion <NUM> of the volatile memory <NUM>, outside the first portion <NUM>, is allocated to a heap <NUM>.

According to the second embodiment of the invention, the first portion <NUM> of the volatile memory <NUM> may be shared between data elements of both the JCVM stack <NUM> and the OS stack <NUM> without the heap <NUM> separating the two stacks <NUM> and <NUM>, meaning that data elements of the OS stack <NUM> may make use of all memory spaces of the first portion <NUM> which are not occupied by any data elements of the JCVM stack <NUM>, and vice versa, hence increasing the maximum number of data elements that can be stored in each of the two stacks <NUM> and <NUM> without allocating additional memory areas to the OS stack <NUM> or to the JCVM stack <NUM>. This particular method for managing the volatile memory <NUM> thus allows improving usage of the volatile memory and reduces manufacturing cost of the Java Card device <NUM>.

As illustrated by <FIG>, in a particular example, the method according to the second embodiment of the invention may further comprise an operation S504, where a fourth portion <NUM> of the volatile memory <NUM> is allocated to an initialized segment <NUM>. The initialized segment <NUM> stores initialized and/or uninitialized global variables, and/or, stores static local variables. The first portion <NUM>, the third portion <NUM> and the fourth portion <NUM> of the volatile memory <NUM> do not overlap. The third portion <NUM> may lie between the first portion <NUM> and the fourth portion <NUM> of the volatile memory <NUM>. For example, the third portion <NUM> may be adjacent to the fourth portion <NUM> and the first portion <NUM>, respectively, in the virtual address space.

Implementation orders of the operations S501-S504 are interchangeable, and the operations S501-S504 may be implemented independently of each other. For example, the operations S501-S504 may be performed at the same time. The operations S501-S504 may also be implemented during link-time of the software system or all software of the Java Card device <NUM> before the software system is loaded onto the Java Card device <NUM>.

In an implementation of the second embodiment, the method may further include the following operation: determining the size of the first portion. For example, as illustrated by <FIG>, the method according to the second embodiment of the invention may further comprise the following operations S701 and S702.

At the operation S701, third maximum memory consumption, C3max, of the JCVM stack <NUM> and the OS stack <NUM> may be assessed.

At different moments, a total amount of volatile memory, or cumulated memory within the volatile memory <NUM>, consumed by data elements of both the JCVM stack <NUM> and the OS stack <NUM> may be different. The third maximum memory consumption, C3max, refers to a maximum of volatile memory consumed by data elements of both the JCVM stack <NUM> and the OS stack <NUM> at one moment.

For example, at any moment tx, the total amount of volatile memory consumed by data elements of both the JCVM stack <NUM> and the OS stack <NUM> is Cx. The third maximum memory consumption, C3max, consumed by data elements of the two stacks <NUM> and <NUM> at a moment t3max, is not less than any cumulated memory consumed by data elements of the two stacks <NUM> and <NUM> within the volatile memory <NUM> at any other moment.

The third maximum memory consumption, C3max, may be assessed by using a complete feature testing method. The complete feature testing method tests each feature of one or more Java applets and/or native code to be loaded onto the Java Card device <NUM>. The features may be defined as changes that add new functionality to or modify existing functionality of the software system of the Java Card device <NUM>. An aim of the complete feature testing method is to make sure that software system meets all intended requirements.

For example, during implementation of the complete feature testing method, the amount of volatile memory consumed by data elements of both the JCVM stack <NUM> and the OS stack <NUM> is logged over time to observe the maximum of volatile memory consumed by data elements of both stacks <NUM> and <NUM>, that is, the third maximum memory consumption, C3max.

At the operation S702, the size of the first portion <NUM> may be determined by adding the size of a buffer to the third maximum memory consumption, C3max.

At the operation S702, the size of the buffer is added to the third maximum memory consumption, C3max, to calculate the size of the first portion <NUM> to avoid stack overflow of either the OS stack <NUM> or the JCVM stack <NUM>.

The size of the buffer is greater than zero and may be determined as a function of the third maximum memory consumption, C3max. , the size of the buffer may be determined as <NUM>% of the third maximum memory consumption, C3max.

In another particular example, the first portion <NUM> stores the whole OS stack <NUM> and the whole JCVM stack <NUM>. The method according to the second embodiment of the invention may further include the following operation: configuring/determining the size of the first portion <NUM> to be smaller than a sum of second maximum memory consumption of the JCVM stack <NUM> and first maximum memory consumption of the OS stack <NUM>. The second maximum memory consumption of the JCVM stack <NUM> is maximum memory consumed by data elements of the JCVM stack <NUM> within the volatile memory <NUM> when the JCVM thread <NUM> runs. The first maximum memory consumption of the OS stack <NUM> is maximum memory consumed by data elements of the OS stack <NUM> within the volatile memory <NUM> during execution of the native code.

Accordingly, the first portion <NUM> of the volatile memory <NUM> may be allocated to the OS stack <NUM> at the operation S501 after the size of the first portion <NUM> is determined, and/or, according to the determined size of the first portion <NUM>.

In order to perform each of the operations S501-S504, the method according to the second embodiment of the invention may include operation(s) of determining the start address of and/or end address of the corresponding portion of the volatile memory <NUM>. For example, to allocate the first portion <NUM> to the OS stack <NUM> at the operation S501, the method according to the second embodiment of the invention may include the operation(s) of determining the start address of and/or end address of the first portion <NUM>.

The start or end address of each of the first, second, third and fourth portion <NUM>-<NUM> of the volatile memory <NUM> may be determined according to a specified value (such as determined to be the specified value), which can be obtained directly from a script used for performing said operation of determining the start or end address of the corresponding portion of the volatile memory <NUM>, or according to the start address of, end address of, or size of another portion of the volatile memory <NUM> adjacent to the corresponding portion, or according to sizes of data elements stored in the corresponding portion. For example, the third portion <NUM> is adjacent to the fourth portion <NUM>, first portion <NUM> and the second portion <NUM>.

In a particular example, the operations S501-S504 may be performed by a processor executing a linker script file. The processor is part of the device or system for managing the volatile memory <NUM>. The linker script file may be stored outside of the Java Card device <NUM>. Accordingly, the start or end address of each portion of the volatile memory <NUM> may be determined according to a specified value of a location counter in the linker script file.

The start address of the OS stack <NUM> may equal the start or end address of the first portion <NUM>. Accordingly, said operation of determining the start or end address of the first portion <NUM> may be implemented by determining the start address of the OS stack <NUM>. For example, as illustrated by an operation S5011 of <FIG>, said operation of determining the start address of the OS stack <NUM> may be performed according to a specified first value. A specified value herein refers to a value which is directly defined or set in the script used for performing the operation (e.g., in a linker script file), such as 0x8000000.

The end address of the OS stack <NUM> is different from its start address. Alternatively or additionally, the end address of the OS stack <NUM> may equal the start or end address of the first portion <NUM>. Accordingly, said operation of determining the start or end address of the first portion <NUM> may be implemented by determining the end address of the OS stack <NUM>. For example, as illustrated by an operation S5012 of <FIG>, said operation of determining the end address of the OS stack <NUM> may be performed according to a specified second value.

In a particular example, the first value may be specified as the highest address of the volatile memory <NUM>, and the second value may be specified as the difference between the highest address of the volatile memory <NUM> and the determined size of the first portion <NUM>.

By setting the start and end addresses of the first portion <NUM> to be the specified first and second values, respectively, the size of the first portion <NUM> may be set to avoid overflow of either the JCVM stack <NUM> or the OS stack <NUM>.

The start and end addresses of the second portion <NUM> may equal the start and end addresses of the JCVM stack <NUM>, respectively. Accordingly, said operation of determining the start or end address of the second portion <NUM> may be implemented by determining the start or end address of the JCVM stack <NUM>, respectively. The end address of the JCVM stack <NUM> is different from its start address.

The start address of the JCVM stack <NUM> may be determined according to a specified third value as illustrated by the operation S5021 in <FIG>. The start address of the JCVM stack <NUM> may equal the start address or end address of the first portion <NUM>. For example, the specified third value may equal the specified second value.

The end address of the JCVM stack <NUM> may be determined according to a specified fourth value as illustrated by the operation S5022 in <FIG>. The end address of the JCVM stack <NUM> may equal the start address or end address of the first portion <NUM>. For example, the specified fourth value may equal the specified first value.

The start and end address of the third portion <NUM> may equal the start and end address of the heap <NUM>, respectively. In an example, the start address of the third portion <NUM> or of the heap <NUM> may be determined according to the end address of an adjacent portion of the volatile memory, or according to a sum of the start address and size of the adjacent portion as illustrated by the operation S5031 in <FIG>. The start address of the third portion <NUM> or of the heap <NUM> may equal the sum, immediately follow the end address of the adjacent portion, or there may be a gap between the start address of the third portion and the end address of the adjacent portion.

For example, the third portion <NUM> is placed after the fourth portion <NUM> in the virtual memory space of the volatile memory <NUM>. Then the start address of the third portion <NUM> may be determined as the sum of the start address and size of the fourth portion <NUM>.

In another example, the end address of the third portion <NUM> or of the heap <NUM> may be determined according to the start address of an adjacent portion of the volatile memory as illustrated by the operation S5032 of <FIG>, and may immediately before the start address of the adjacent portion or there may be a gap between the end address of the third portion and the start address of the adjacent portion.

In an example, the third portion <NUM> is placed before the first portion <NUM> in the virtual memory space of the volatile memory <NUM>. Then the end address of the third portion <NUM> may be determined according to the start address of the first portion <NUM>.

By determining the start and end addresses of the third portion <NUM> according to the end address of one adjacent portion and the start address of another adjacent portion, respectively, the third portion <NUM> may make use of free memory spaces within the volatile memory <NUM> between the two portions adjacent to the third portion <NUM> after sufficient memory areas have been allocated to said two portions.

The start and end address of the fourth portion <NUM> may equal the start and end address of the initialized segment <NUM>, respectively. The start address of the fourth portion <NUM> may be determined to be a specified fifth value, such as the lowest address of the volatile memory <NUM>. The end address of the fourth portion <NUM> may be determined according to the size of the fourth portion <NUM> and the start address of the fourth portion <NUM>. The size of the fourth portion <NUM> may be determined according to the sum of the sizes of the data elements (such as the global variables and/or static local variables) stored in the initialized segment <NUM>, e.g., after the data elements are compiled by the device for system for managing the volatile memory <NUM>.

By determining the size of the fourth portion <NUM> according to the sizes of the data elements stored in the initialized segment <NUM>, it is ensured that sufficient memory spaces within the volatile memory <NUM> are allocated to the initialized segment <NUM> to contain all the global variables and/or static local variables that need to be stored in the initialized segment <NUM>.

In an implementation of the second embodiment, the method further includes the following operations: configuring addresses occupied by data elements in the JCVM stack <NUM> to grow from the start address <NUM> of the JCVM stack <NUM> towards the start address <NUM> of the OS stack <NUM>, as the number of the data elements in the JCVM stack <NUM> increases; and configuring addresses occupied by data elements in the OS stack <NUM> to grow from the start address <NUM> of the OS stack <NUM> towards the start address <NUM> of the JCVM stack <NUM>, as the number of the data elements in the OS stack <NUM> increases.

In another implementation of the second embodiment, the method further includes the following operation: configuring the location, relative to one end of the first portion, of a boundary between one data element of the JCVM stack <NUM> and one adjacent data element of the OS stack <NUM> to vary dynamically as the number of data elements in the JCVM stack <NUM> and the number of data elements in the OS <NUM> stack vary.

Different operations according to the various implementations of the second embodiment of the invention may be performed by different devices or the same device.

It should be noted that, in some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, or blocks may be executed in an alternative order, depending upon the functionality involved.

According to a third embodiment of the invention, the method according to the second embodiment of the invention may be performed by a device or system <NUM> for managing the volatile memory as illustrated by <FIG>. The device or system <NUM> may include the Java Card device <NUM> or a part thereof (such as the processor <NUM>), and/or, may include one or more devices independent of the Java Card device <NUM>. As illustrated by <FIG>, the device <NUM> for managing the volatile memory comprises one or more memories represented by the memory <NUM> and one or more processors represented by the processor <NUM>. The processor <NUM> as illustrated by <FIG> may be the same as the processor <NUM> as illustrated by <FIG>. The memory <NUM> is configured to store one or more instructions, and the processor <NUM> is configured to execute the one or more instructions to perform the method according to the second embodiment of the invention (that is, according to any of the implementations/examples above of the second embodiment of the invention).

According to a fourth embodiment of the invention, the method according to the second embodiment of the invention may be performed by a device or system <NUM> for managing the volatile memory as illustrated by <FIG>. The device or system <NUM> may include the Java Card device <NUM> or a part thereof (such as the processor <NUM>), and/or, may include one or more devices independent of the Java Card device <NUM>. The device or system <NUM> may be the same as the device or system <NUM>. As illustrated by <FIG>, the device or system <NUM> for managing the volatile memory may be implemented in the form of modules.

The various implementations of the first embodiment defined above in connection with the Java Card device <NUM>, and of the second embodiment defined above in connection with the method for managing the volatile memory, may apply in an analogous manner to the device or system <NUM> according to the fourth embodiment of the invention.

As illustrated by <FIG>, the device or system <NUM> comprises a first allocating module <NUM>, a second allocating module <NUM> and a third allocating module <NUM>.

The first allocating module <NUM> is configured to perform the operation S501 described above with reference to <FIG>, of allocating the first portion <NUM> of the volatile memory <NUM> to the OS stack <NUM>.

The second allocating module <NUM> is configured to perform the operation S502 described above with reference to <FIG>, of allocating the second portion <NUM> of the volatile memory <NUM> to the JCVM stack <NUM>.

The third allocating module <NUM> is configured to perform the operation S503 described above with reference to <FIG>, of allocating the third portion <NUM> of the volatile memory <NUM> to the heap <NUM>.

The invention may be implemented using software and/or hardware components. In this context, the term "module" can refer in this document to a software component, as well as a hardware component or a plurality of software and/or hardware components.

As illustrated by <FIG>, the device or system <NUM> for managing the volatile memory according to the fourth embodiment of the invention may further comprise a fourth allocating module <NUM>. The fourth allocating module <NUM> is configured to perform the operation of S504 described above with reference to <FIG>, of allocating the fourth portion <NUM> of the volatile memory <NUM> to the initialized segment <NUM> for storing global variables and/or static local variables.

As illustrated by <FIG>, the device or system <NUM> for managing the volatile memory according to the fourth embodiment of the invention may further comprise an assessing module <NUM> and a determining module <NUM>.

The assessing module <NUM> may be configured to perform the operation S701 described above with reference to <FIG>, of assessing the third maximum memory consumption of the JCVM stack <NUM> and the OS stack <NUM>.

The determining module <NUM> may be configured to perform the operation S702 described above with reference to <FIG>, of determining the size of the first portion <NUM> by adding the size of the buffer to the third maximum memory consumption.

As illustrated by <FIG>, the first allocating module <NUM> may comprise a first determining sub-module <NUM>. The first determining sub-module <NUM> is configured to perform the operation of S5011 described above with reference to <FIG>, of determining the start address of the OS stack <NUM> according to a specified first value.

As illustrated by <FIG>, the first allocating module <NUM> may comprise a second determining sub-module <NUM>. The second determining sub-module <NUM> is configured to perform the operation of S5012 described above with reference to <FIG>, of determining the end address of the OS stack <NUM> according to a specified second value.

As illustrated by <FIG>, the second allocating module <NUM> may comprise a third determining sub-module <NUM>. The third determining sub-module <NUM> may be configured to perform the operation of S5021 described above with reference to <FIG>, of determining the start address of the JCVM stack <NUM> according to a specified third value.

As illustrated by <FIG>, the second allocating module <NUM> may comprise a fourth determining sub-module <NUM>. The fourth determining sub-module <NUM> may be configured to perform the operation of S5022 described above with reference to <FIG>, of determining the end address of the JCVM stack <NUM> according to a specified fourth value.

As illustrated by <FIG>, the third allocating module <NUM> may comprise a fifth determining sub-module <NUM>. The fifth determining sub-module <NUM> may be configured to perform the operation of S5031 described above with reference to <FIG>, of determining the start address of the third portion <NUM> according to the sum of the start address of an adjacent portion in the volatile memory <NUM> and the size of the adjacent portion.

As illustrated by <FIG>, the third allocating module <NUM> may comprise a sixth determining sub-module <NUM>. The sixth determining sub-module <NUM> may be configured to perform the operation of S5032 described above with reference to <FIG>, of determining the end address of the third portion <NUM> according to the start address of an adjacent portion in the volatile memory <NUM>.

According to an implementation of the fourth embodiment of the invention, operation of various modules of the device or system <NUM> is controlled using a specific applicative software implemented by the device or system <NUM>.

A computer-readable storage medium according to a fifth embodiment of the invention is configured to store one or more instructions. When executed by a processor, said one or more instructions causes the processor to perform the method according to the second embodiment of the invention.

Another aspect of the invention pertains to a computer program product downloadable from a communication network and/or recorded on a medium readable by computer and/or executable by a processor, comprising program code instructions for implementing the operations of the method according to the second embodiment of the invention.

The various embodiments and variants described in this document in relation with the method of the invention applies in an analogous manner to the devices of the present invention, and conversely.

While not explicitly described, the present embodiments may be employed in any combination or combination.

It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of the blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems that perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

As will be appreciated by one skilled in the art, aspects of the present principles can be embodied as a system, method, computer program or computer readable medium. Accordingly, aspects of the present principles can take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, and so forth), or an embodiment combining software and hardware aspects that can all generally be referred to herein as a "circuit," "module", or "system.

Furthermore, aspects of the present principles can take the form of a computer readable storage medium. Any combination of one or more computer readable storage medium(s) may be utilized. A computer readable storage medium can take the form of a computer readable program product embodied in one or more computer readable medium(s) and having computer readable program code embodied thereon that is executable by a computer. A computer readable storage medium as used herein is considered a non-transitory storage medium given the inherent capability to store the information therein as well as the inherent capability to provide retrieval of the information therefrom. A computer readable storage medium can be, for example, but is not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing.

It is to be appreciated that the following, while providing more specific examples of computer readable storage mediums to which the present principles can be applied, is merely an illustrative and not exhaustive listing as is readily appreciated by one of ordinary skill in the art: a portable computer disc, a hard disc, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

Claim 1:
A Java Card device (<NUM>), comprising:
- a volatile memory (<NUM>);
- an operating system, OS (<NUM>); and
- a Java Card virtual machine, JCVM (<NUM>), comprising a JCVM thread (<NUM>); characterized in that, the volatile memory (<NUM>) comprises:
- a first portion (<NUM>) allocated to an OS stack (<NUM>) for supporting execution of native code defined in a language used for programming the OS (<NUM>);
- a second portion (<NUM>) within the first portion (<NUM>), allocated to a JCVM stack (<NUM>) for supporting the JCVM thread (<NUM>); and
- a third portion (<NUM>) outside the first portion (<NUM>), allocated to a heap (<NUM>).