Secure allocation of volatile memory for smart card application design in embedded systems
By employing an object entity volatile memory allocation system on smart cards and dynamically allocating memory using volatile memory allocation type keywords, the problem of smart card memory limitations is solved, achieving efficient memory utilization and normal operation of applications.
Patent Information
- Application Number
- CN202380095746.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2023-05-25
- Publication Date
- 2025-11-11
AI Technical Summary
The memory limitations on smart cards lead to memory constraints in smart card application design, and existing technologies struggle to effectively utilize limited storage space.
An object entity volatile memory allocation system is adopted, which dynamically allocates memory on the smart card using objects and object references generated by an object-oriented programming language and volatile memory allocation type keywords. This includes using keywords such as 'transient' and 'TRANSIENT' from Java or other high-level object-oriented programming languages to allocate volatile memory for objects and object references at runtime.
It optimizes memory utilization, allowing efficient access and management of objects within limited storage space, ensuring the normal operation of smart card applications, and improving the flexibility and efficiency of memory allocation.
Smart Images

Figure CN120937030A_ABST
Abstract
Description
Background Technology
[0001] The background description provided herein is for the purpose of generally presenting the context of this disclosure. To the extent described in this background section, the work of the currently identified inventors and aspects described at the time of filing that may not otherwise be considered prior art are neither expressly nor implied to be prior art to this disclosure.
[0002] Many consumers use smart cards to perform various financial transactions. The memory available on a smart card for executing and storing smart card applications is limited by the finite amount of space available on the card. Therefore, smart card application engineers often encounter design problems when using object-oriented design to design smart card applications. For example, memory constraints associated with storing objects on the smart card's memory often hinder the design of smart applications. Therefore, there is a need to develop techniques for designing smart applications that take into account the memory constraints on smart cards. Attached Figure Description
[0003] Figure 1 A block diagram of a smart card according to some embodiments is shown.
[0004] Figure 2 This diagram illustrates a block diagram of an object entity volatile memory allocation system, according to some embodiments, including non-volatile memory for allocation. Figure 1 The volatile memory in the smart card.
[0005] Figure 3 This is a flowchart illustrating an object reference volatile memory allocation method according to some embodiments.
[0006] Figure 4 This is a flowchart illustrating an object volatile memory allocation method according to some embodiments. Detailed Implementation
[0007] Figure 1A block diagram of a smart card 100 according to some embodiments is shown. In some embodiments, the smart card 100 includes an embedded microcontroller 105, which includes a microprocessor 110, random access memory (RAM) 120, read-only memory (ROM) 130, non-volatile memory 140, a cryptographic module 150, a card reader interface 160, and volatile memory 180. In some embodiments, the smart card 100 is configured to allocate volatile memory of the volatile memory 180 to object entities for executing smart card applets on the smart card 100 using an object entity volatile memory allocation system 170. In some embodiments, the object entity may be, for example, an object and / or object reference generated using an object-oriented programming language (e.g., Java or other high-level object-oriented programming languages). In some embodiments, an object reference refers to a variable that holds a reference to an instance of an object, where the object is an instance of a class. In some embodiments, in order to allocate volatile memory for object entities 180, an object entity volatile memory allocation system 170 (executed by microcontroller 110) is configured to allocate volatile memory for object entities (e.g., objects and / or object references) using a volatile memory allocation type keyword defined in a smart card applet installed on smart card 100. In some embodiments, the object entity volatile memory allocation system 170 allows smart card applets (e.g., Java applets, which traditionally do not have access to volatile memory for storing object entities) installed on smart card 100 to access volatile memory for storage and execution during runtime, as referenced herein. Figures 1 to 4 Further description.
[0008] In some embodiments, further references Figure 1 The microprocessor 110 is any suitable central processing unit used to execute commands and control the smart card 100. In some embodiments, RAM 120 serves as a storage device for calculation results and a stack memory. In some embodiments, ROM 130 stores the operating system, fixed data, standard routines, and lookup tables. In some embodiments, RAM 120 may serve as volatile memory 180, or vice versa.
[0009] In some embodiments, the cryptographic module 150 is an optional hardware module for executing various cryptographic algorithms. The reader interface 160 includes the software and hardware necessary for communication with the outside world. Multiple interfaces are possible. For example, the reader interface 160 may provide a contact interface, a tightly coupled interface, a remotely coupled interface, or various other interfaces. Using the contact interface, signals from the microcontroller are routed to multiple metal contacts on the exterior of the card that physically contact similar contacts of the reader device.
[0010] In some embodiments, non-volatile memory 140 includes an object entity volatile memory allocation system 170. In some embodiments, the object entity volatile memory allocation system 170 is executable code configured to allocate volatile memory of volatile memory 180 to object entities for executing smart card applets on smart card 100. In some embodiments, the non-volatile memory may be, for example, an EPROM or EEPROM, used to store information that must not be lost when smart card 100 is disconnected from power, but must also be modifiable to accommodate data specific to an individual smart card or any changes that may occur during the smart card's lifespan. In some embodiments, additional information stored in non-volatile memory 140 may include, for example, card identification number, personal identification number, authorization level, cash balance, credit limit, or other information related to financial transactions associated with smart card 100.
[0011] Figure 2 A block diagram of an object entity volatile memory allocation system 170 according to some embodiments is shown. In some embodiments, as previously described, the object entity volatile memory allocation system 170 is executable code configured to perform object entity allocation of volatile memory 180 for smart card applets 250 on smart card 100. In some embodiments, as previously described, the object entity may be, for example, an object and / or object reference generated using an object-oriented programming language such as Java or other high-level object-oriented programming languages for generating smart card applets or applications for smart card 100. In some embodiments, the smart card applet 250 is an object-oriented programming smart card applet that, in addition to being configured to execute on smart card 100, is also configured to define transient memory allocation object entity code (e.g., transient memory allocation object code and / or transient memory allocation object reference code) used by the object entity volatile memory allocation system 170 to allocate volatile memory 180. In some embodiments, the object entity volatile memory allocation system 170 utilizes the object reference volatile memory allocation method 300 (referenced herein). Figure 3 (further description) and / or object volatile memory allocation method 400 (referenced herein) Figure 4 (Further description) to allocate volatile memory 180 to the object entity.
[0012] Volatile memory allocation for object references during the installation of smart card app 250 on smart card 100
[0013] In some embodiments, the object entity volatile memory allocation system 170 includes a smart card applet evaluation and allocation unit 241 of the smart card applet installation unit 220 and a smart card applet evaluation and allocation unit 242 of the smart card virtual machine (SCVM) 230. In some embodiments, the smart card applet installation unit 220 is executable code that, in addition to being configured to perform tasks associated with installing the smart card applet 250 onto the smart card 100, is also configured to utilize the smart card applet evaluation and allocation unit 241 to perform a transient memory allocation object reference code evaluation of the smart card applet 250 in order to allocate volatile memory of the volatile memory 180 for object references defined in the smart card applet 250. In some embodiments, the transient memory allocation object reference code evaluation is an evaluation of the smart card applet 250 performed by the smart card applet evaluation and allocation unit 241 for the transient memory allocation object reference code, wherein the transient memory allocation object reference code is executable code in the smart card applet 250 that instructs the allocation of volatile memory 180 for an object reference defined in the smart card applet 250. In some embodiments, the transient memory allocation object reference code is defined in the smart card applet 250 and includes a volatile memory allocation object reference type keyword. In some embodiments, the volatile memory allocation object reference type keyword is a keyword in the smart card applet 250 that instructs the allocation of volatile memory 180 for storing an object reference in volatile memory 180. In some embodiments, the volatile memory allocation object reference type keyword may be a transient memory allocation object reference type keyword, such as the keyword "transient" preceding the object reference (e.g., public transient MyClass objectRef shown in the Java code below in the volatile memory allocation object reference example). In some embodiments, the use of the transient memory allocation object reference type keyword to allocate volatile memory from volatile memory 180 is illustrated using object-oriented programming in the following Java code:
[0014]
[0015] In some embodiments, in the volatile memory allocation object reference example above, the executable code in smart card applet 250 defines an object reference (e.g., objectRef) as volatile memory allocated to volatile memory 180. As a result, during the installation of smart card applet 250 by smart card applet installation unit 220, smart card applet evaluation and allocation unit 241 allocates volatile memory of volatile memory 180 for the object reference defined using the volatile memory allocation object reference type keyword. Similar to allocating volatile memory of volatile memory 180 for an object reference using smart card applet evaluation and allocation unit 241 as described herein, this document also describes allocating volatile memory of volatile memory 180 for an object (or object instance) using smart card applet evaluation and allocation unit 242 during runtime.
[0016] Allocate volatile memory to the object during smart card operation.
[0017] In some embodiments, in order to allocate volatile memory of volatile memory 180 to an object during the runtime of smart card 100, object entity volatile memory allocation system 170 utilizes smart card applet evaluation and allocation unit 242 of SCVM 230. In some embodiments, SCVM 230 is executable code that, in addition to being configured to perform conventional smart card virtual machine tasks (e.g., interpreting and executing bytecode instructions, managing memory and resources, and providing the necessary runtime environment for smart card applets), is also configured to utilize smart card applet evaluation and allocation unit 242 to perform transient memory allocation object code evaluation of smart card applet 250, and allocate volatile memory of volatile memory 180 to objects defined in smart card applet 250 based on the transient memory allocation object code evaluation. In some embodiments, transient memory allocation object code evaluation is performed on smart card app 250, where the transient memory allocation object code is executable code in smart card app 250 that instructs the allocation of volatile memory 180 for an object defined in smart card app 250. In some embodiments, the transient memory allocation object code is defined in smart card app 250 and includes a volatile memory allocation object type keyword. In some embodiments, the volatile memory allocation object type keyword is a keyword in smart card app 250 that instructs the allocation of volatile memory 180 for storing an object in volatile memory 180. In some embodiments, the volatile memory allocation object type keyword may be a transient memory allocation object type keyword, such as the keyword "TRANSIENT" used in a set allocation type method (e.g., System.setAllocationType(System.TRANSIENT), where setAllocationType is a method configured to set an allocation type (e.g., "TRANSIENT" type) defined in the set allocation type method). In some embodiments, the following code illustrates an example of allocating volatile memory from volatile memory 180 using a transient memory allocation object type keyword:
[0018]
[0019] In some embodiments, in the volatile memory allocation object example above, the executable code in smart card applet 250 defines an object (e.g., MyClass) as volatile memory allocated to volatile memory 180. In some embodiments, smart card applet 250 uses a set allocation type (e.g., setAllocationType) with the transient memory allocation object type keyword “TRANSIENT” to instruct smart card applet evaluation and allocation unit 242 during runtime to allocate volatile memory of volatile memory 180 to an object defined using “new” in an object-oriented programming language (e.g., objectRef = new MyClass();). In some embodiments, setAllocationType is a method or predefined code, such as a cursor, configured to allocate an object using the transient memory allocation object type keyword (e.g., TRANSIENT). In some embodiments, during the runtime of smart card applet 250 by smart card applet installation unit 220, smart card applet evaluation and allocation unit 241 allocates volatile memory of volatile memory 180 to the object defined using the transient memory allocation object type keyword. In some embodiments, the DEFAULT keyword is used by the smart card applet 250 to set the allocation type (e.g., System.setAllocationType(System.DEFAULT)) to stop allocating volatile memory 180 for additional objects that are not defined using the transient memory allocation object type keyword (System.setAllocationType(System.TRANSIENT)), and utilizes the default memory allocation mode (e.g., non-volatile memory allocation mode) defined in the smart card applet 250 and / or the smart card 100. In some embodiments, references herein are made to... Figure 3 and Figure 4 Further described as object reference and object allocation volatile memory 180.
[0020] Figure 3This is a flowchart illustrating an object reference volatile memory allocation method 300 according to some embodiments. In some embodiments, the object reference volatile memory allocation method 300 is used by a smart card applet evaluation unit and allocation unit 241 of an object entity volatile memory allocation system 170 to allocate volatile memory 180 to object references defined in a smart card applet 250 using transient memory allocation object reference type keywords. In some embodiments, the methods, process steps, or stages shown in the figures may be implemented as independent routines or processes, or as part of a larger routine or process. It should be noted that in other embodiments, each process step or stage depicted may be implemented as a device, method, or system including a processor executing a set of instructions. In some embodiments, the object reference volatile memory allocation method 300 is described with reference to the figures described herein.
[0021] In some embodiments, at operation 310, the smart card approximation and allocation unit 241 of the smart card approximation installation unit 220 receives the smart card approximation 250 from an external entity, such as a card issuer or card management system, and begins the process of installing the smart card approximation 250 onto the non-volatile memory 140. In some embodiments, as previously described, the smart card approximation 250 is an object-oriented programmable smart card approximation that, in addition to being configured to execute on the smart card 100, is also configured to define transient memory allocation object entity code used by the object entity volatile memory allocation system 170 to allocate volatile memory 180. In some embodiments, after receiving the smart card approximation 250, operation 310 proceeds to operation 320.
[0022] In some embodiments, at operation 320, during the installation process of smart card applet 250, smart card applet evaluation and allocation unit 241 evaluates smart card applet 250 to determine whether an object reference in smart card applet 250 has been designated for allocating volatile memory in volatile memory 180 (e.g., by performing a transient memory allocation object reference code evaluation of smart card applet 250). In some embodiments, smart card applet evaluation and allocation unit 241 performs transient memory allocation object reference code evaluation by performing an evaluation of smart card applet 250 for a transient memory allocation object reference code indicating that volatile memory 180 is allocated for an object reference defined in smart card applet 250. In some embodiments, as described above, transient memory allocation object reference code includes a volatile memory object reference allocation type keyword, which may be a transient memory allocation object reference type keyword, such as the keyword "transient" associated with an object reference. In some embodiments, for reference Figure 2The given example, for smart card 100 (e.g., a Java card utilizing the Java object-oriented programming language), can use the transient memory allocation object reference type keyword "transient" in the following Java code "public transient MyClass objectRef" to allocate volatile memory for volatile memory 180, as previously referenced in this article. Figure 2 As described. In some embodiments, as part of the transient memory allocation object reference code evaluation, the smart card applet evaluation and allocation unit 241 examines the bytecode of the smart card applet 250 and examines the class hierarchy, static fields, constant pool, and methods in the smart card applet 250. In some embodiments, during the transient memory allocation object reference code evaluation, when the smart card applet evaluation and allocation unit 241 identifies the object reference and determines (using the transient memory allocation object reference type keyword) that the object reference requires volatile memory allocation from the volatile memory 180, operation 320 proceeds to operation 330.
[0023] In some embodiments, at operation 330, when an object reference is identified as a transient memory allocation object reference type, the smart card approximation and allocation unit 241 allocates volatile memory of volatile memory 180 for the object reference. In some embodiments, object reference volatile memory allocation involves reserving a specific portion of volatile memory 180 dedicated to the object reference (e.g., objectRef) and its associated data. In some embodiments, by allocating memory during the installation process, the smart card approximation and allocation unit 241 ensures that the object reference has a predetermined volatile memory space available for efficient access and management during the execution of the smart card approximation 250 on the smart card 100. In some embodiments, the embodiments described herein improve upon existing memory allocation systems and techniques by optimizing the utilization of volatile memory 180 during the installation of the smart card approximation 250 and facilitating the proper operation of the smart card approximation 250 for the identified object reference. For example, in some embodiments, the embodiments described herein improve upon other memory allocation systems by allowing updates to dynamic variables without putting pressure on memory, enabling fast memory access when retrieving data, and saving stack space by not having to pass object references in method arguments during method calls, while keeping application design within appropriate object-oriented design methods, for example.
[0024] Figure 4This is a flowchart illustrating an object volatile memory allocation method 400 according to some embodiments. In some embodiments, the object volatile memory allocation method 400 is used by a smart card applet evaluation unit and allocation unit 242 of an object entity volatile memory allocation system 170 to allocate volatile memory 180 to objects defined in a smart card applet 250 using transient memory allocation object type keywords. In some embodiments, the methods, process steps, or stages shown in the figures may be implemented as independent routines or processes, or as part of a larger routine or process. It should be noted that in other embodiments, each process step or stage depicted may be implemented as a device, method, or system including a processor executing a set of instructions. In some embodiments, the object volatile memory allocation method 400 is described with reference to the figures described herein.
[0025] In some embodiments, at operation 410, the smart card approximation and allocation unit 241 of the smart card approximation installation unit 220 receives the smart card approximation 250 and installs the smart card approximation 250 onto the non-volatile memory 140. In some embodiments, as previously described, the smart card approximation 250 is an object-oriented programming approximation that, in addition to being configured to execute on the smart card 100, is also configured to define transient memory allocation object entity code used by the object entity volatile memory allocation system 170 to allocate volatile memory 180. In some embodiments, after receiving and installing the smart card approximation 250, operation 410 proceeds to operation 420.
[0026] In some embodiments, at operation 420, SCVM 230 interprets and executes code in smart card applet 250 during runtime within the smart card runtime environment of smart card 100. In some embodiments, the smart card runtime environment may be, for example, a Java card runtime environment, where methods in smart card applet 250 may be invoked in response to various events or commands. In some embodiments, the execution of smart card applet 250 generally follows a specific lifecycle, which includes the selection and initialization of smart card applet 250, command processing, and termination or deselection of smart card applet 250. In some embodiments, the smart card runtime environment manages the execution of smart card applet 250, performing some of the embodiments described herein (including, for example, performing some of the methods described herein (e.g., object volatile memory allocation method 400)) and providing the security and integrity features further described herein. In some embodiments, during the execution of smart card applet 250, operation 420 proceeds to operation 430.
[0027] In some embodiments, at operation 430, during runtime execution of smart card applet 250, smart card applet evaluation and allocation unit 242 performs transient memory allocation object code evaluation of smart card applet 250. In some embodiments, smart card applet evaluation and allocation unit 242 performs transient memory allocation object code evaluation by performing an evaluation of smart card applet 250 for a transient memory allocation object type keyword indicating that volatile memory 180 is allocated to an object defined in smart card applet 250. In some embodiments, as previously described, the volatile memory object allocation type keyword can be a transient memory allocation object type keyword, such as the keyword "TRANSIENT" used in the set allocation type method (e.g., System.setAllocationType(System.TRANSIENT), where setAllocationType is a cursor or cursor-based method configured to set the allocation type type (e.g., "TRANSIENT" type) defined in the method). In some embodiments, the cursor-based method is a method that utilizes transient memory allocation of object type keywords and has a start point (e.g., a start object volatile memory allocation point) and a stop point (e.g., a stop object volatile memory allocation point) for the object's volatile memory allocation. For example,
[0028] System.setAllocationType(System.TRANSIENT) can be an indication of the starting point of one or more objects defined before the stopping point but after System.setAllocationType(System.TRANSIENT) is allocated volatile memory in volatile memory 180. In some embodiments, System.setAllocationType(System.DEFAULT) can be an indication of the starting point of one or more objects defined before the stopping point but after System.setAllocationType(System.TRANSIENT) is allocated volatile memory in volatile memory 180.
[0029] The allocation of volatile memory 180, indicated by System.setAllocationType(System.TRANSIENT), should stop at the point where System.setAllocationType(System.DEFAULT) stops.
[0030] In some embodiments, during transient memory allocation object code evaluation, the smart card applet evaluation and allocation unit 242 examines bytecode instructions, class relationships, static fields, constant pool entries, and method calls to identify objects intended for volatile memory allocation in volatile memory 180. In some embodiments, during transient memory allocation object reference evaluation, when the smart card applet evaluation and allocation unit 242 identifies an object and determines that the object requires volatile memory allocation from volatile memory 180 using a transient memory allocation object type keyword, operation 430 proceeds to operation 440.
[0031] In some embodiments, at operation 440, when the transient memory allocation object code evaluation indicates that the object should be allocated to the volatile memory of volatile memory 180, the smart card applet evaluation and allocation unit 242 allocates and reserves volatile memory within volatile memory 180. In some embodiments, allocating volatile memory for an object in volatile memory 180 involves reserving a specific portion of volatile memory 180 dedicated to the object and its associated data. In some embodiments, the smart card applet evaluation and allocation unit 242 of SCVM 230 may be configured to dynamically allocate volatile memory from the object heap in volatile memory 180 to create and manage the volatile memory allocated for the object. In some embodiments, the volatile memory from volatile memory 180 is allocated for object instantiation, method calls, and other runtime operations. In some embodiments, by allocating memory during runtime using the embodiments described herein, the smart card approximation and allocation unit 241 ensures that objects and their associated data have predetermined volatile memory space available for efficient access and management during runtime and execution of the smart card approximation 250 on the smart card 100. Furthermore, allocating volatile memory to objects using the embodiments described herein ensures efficient access and modification of the objects during runtime and execution of the smart card approximation 250. In some embodiments, by selectively allocating objects to volatile memory, the smart card approximation and allocation unit 242 optimizes memory utilization and enhances the performance of the smart card 100, thereby allowing for efficient management and execution of the smart card approximation in resource-constrained environments.
[0032] In some embodiments, smart card 100 may include a security and integrity unit. In some embodiments, the security and integrity unit may be executable code configured to perform encryption and checksum operations of the embodiments described herein. In some embodiments, cryptographic module 150 may be configured to perform the operations of the security and integrity unit. In some embodiments, for example, refer to... Figure 2In the example, when volatile memory 180 is allocated for an object at runtime and the object is created (e.g., using "objectRef = new MyClass()"), the security and integrity unit can perform encryption and checksum operations on the newly created object (e.g., MyClass()).
[0033] In some embodiments, for checksum operations, a checksum algorithm is applied to the object's data when the object is created or modified. In some embodiments, the security and integrity unit generates a checksum value based on the object's content and uses the checksum to verify the object's integrity. In some embodiments, for encryption operations, when the object is encrypted by the security and integrity unit, an encryption algorithm and an encryption key are used to process the object's data. In some embodiments, the encryption algorithm determines the data associated with the object and transforms the data associated with the object into ciphertext, which is an encrypted representation of the object's data. In some embodiments, the encryption key may be used by the security and integrity unit to control the encryption process and for decrypting the object.
[0034] In some embodiments, in order to read data associated with an object and an object reference written to volatile memory allocated by the object entity volatile memory allocation system 170, SCVM 230 determines the type of memory where the data is stored (e.g., volatile or non-volatile memory), and if the memory type is transient memory (e.g., volatile memory), SCVM 230 then verifies the checksum. In some embodiments, when the checksum passes verification, smart card app 250 uses the read data for a prescribed action within smart card app 250. In some embodiments, when the data associated with the object and object reference stored in volatile memory 180 has been encrypted by a security and integrity unit, the data is decrypted before processing.
[0035] In some embodiments, in order to release volatile memory allocated by the object entity volatile memory allocation system 170, when the object or object reference is no longer in use, the object or object reference is set to empty, and then the allocated volatile memory is released from volatile memory 180 to a free pool of volatile memory (e.g., volatile memory that can be allocated to a new object or object reference).
[0036] In some embodiments, the object entity volatile memory allocation system can be configured to update the volatile memory for object references or objects or write object entities to the volatile memory for object references or objects during the runtime of the smart card app.
[0037] In some embodiments, a computer-implemented method includes: receiving a smart card app for executing a program on a smart card; determining whether a memory allocation type keyword provided via the smart card app belongs to a transient memory allocation type; and when the memory allocation type keyword belongs to the transient memory allocation type, allocating volatile memory from the smart card for temporarily storing object entities.
[0038] In some embodiments, the computer-implemented method further includes using a transient allocation type keyword to indicate whether the memory allocation type keyword is the transient memory allocation type.
[0039] In some embodiments of the computer-implemented method, the object entity is an object or an object reference.
[0040] In some embodiments of the method implemented by the computer, a start cursor and an end cursor are used during the allocation of the volatile memory for the object.
[0041] In some embodiments of the method implemented by the computer, the start cursor is utilized in the smart card runtime environment during the allocation of the volatile memory.
[0042] In some embodiments of the computer-implemented method, the volatile memory allocated to the object is used for new object instances of the object.
[0043] In some embodiments of the computer-implemented method, the end cursor is used to stop the allocation of volatile memory for the object.
[0044] In some embodiments of the computer-implemented method, transient is the transient assignment type keyword.
[0045] In some embodiments, a computer-implemented method includes: receiving a smart card app at a smart card, the smart card app defining a memory allocation type keyword for allocating memory for an object reference; determining whether the memory allocation type keyword provided via the smart card app is a transient memory allocation type; and when the memory allocation type keyword is the transient memory allocation type, allocating volatile memory from the smart card for temporarily storing the object reference.
[0046] In some embodiments, the computer-implemented method includes using a transient allocation type keyword to indicate whether the memory allocation type keyword is a transient memory allocation type.
[0047] In some embodiments of the computer-implemented method, data is further written into the volatile memory allocated for the object reference.
[0048] In some embodiments of the computer-implemented method, the volatile memory is allocated during the installation of the smart card app.
[0049] In some embodiments of the method implemented by the computer, the volatile memory allocated during the installation of the smart card app is random access memory.
[0050] In some embodiments of the computer-implemented method, when a context switch occurs from the smart card app after the object reference has been stored in the volatile memory, the object reference stored in the volatile memory is retained in the volatile memory so that it can be retrieved after the context switch returns to the smart card app.
[0051] In some embodiments of the computer-implemented method, the memory allocation type keyword provided via the smart card app is a transient memory allocation type, the type of which is determined during the installation of the smart card app onto the smart card.
[0052] In some embodiments of the method implemented by the computer, when the memory allocation type keyword is not the transient memory allocation type, non-volatile memory is allocated from the smart card for storing the object reference.
[0053] In some embodiments, an object entity volatile memory allocation system includes: an object reference smart card app evaluation and allocation unit; and an object smart card app evaluation and allocation unit, wherein the object entity volatile memory allocation system utilizes the object reference smart card app evaluation and allocation unit to allocate volatile memory for an object reference during the installation of the smart card app, and the object entity volatile memory allocation system utilizes the object smart card app evaluation and allocation unit to allocate the volatile memory for an object during the runtime of the smart card app.
[0054] In some embodiments of the object entity volatile memory allocation system, the transient allocation object reference type keyword is used to allocate volatile memory for the object reference during the installation of the smart card app.
[0055] In some embodiments of the object entity volatile memory allocation system, the transient allocation object type keyword is used to allocate the volatile memory for an object during the execution of the smart card app.
[0056] In some embodiments of the object entity volatile memory allocation system, in order to determine whether a keyword in the smart card app is a transient allocation object reference type keyword or a transient allocation object type keyword, the object entity volatile memory allocation system performs transient memory allocation object reference code evaluation and transient memory allocation object code evaluation of the smart card app.
Claims
1. A computer-implemented method comprising: Receive smart card app for use in executing programs on the smart card; Determine whether the memory allocation type keyword provided by the smart card applet belongs to the transient memory allocation type; as well as When the memory allocation type keyword belongs to the transient memory allocation type, volatile memory is allocated from the smart card for temporary storage of object entities.
2. The computer-implemented method according to claim 1, further comprising: Use the transient allocation type keyword to indicate whether the memory allocation type keyword is the transient memory allocation type.
3. The computer-implemented method according to claim 2, wherein: The object entity is an object or an object reference.
4. The computer-implemented method according to claim 3, wherein: A start cursor and an end cursor are used during the allocation of the volatile memory for the object.
5. The computer-implemented method according to claim 4, wherein: During the allocation of the volatile memory, the start cursor is utilized in the smart card runtime environment.
6. The computer-implemented method according to claim 5, wherein: The volatile memory allocated to the object is used for new object instances of the object.
7. The computer-implemented method according to claim 6, wherein: The end cursor is used to stop allocating volatile memory for the object.
8. The computer-implemented method according to claim 7, wherein: Transient is the keyword for the transient assignment type.
9. A computer-implemented method comprising: Receive a smart card mini-program at the smart card, wherein the smart card mini-program defines a memory allocation type keyword for allocating memory for an object reference; Determine whether the memory allocation type keyword provided via the smart card applet is a transient memory allocation type; as well as When the memory allocation type keyword is the transient memory allocation type, volatile memory is allocated from the smart card for temporary storage of the object reference.
10. The computer-implemented method according to claim 9, further comprising: Use the transient allocation type keyword to indicate whether the memory allocation type keyword is the transient memory allocation type.
11. The computer-implemented method according to claim 10, further comprising: The data is written to the volatile memory allocated for the object reference.
12. The computer-implemented method according to claim 11, wherein: The volatile memory is allocated during the installation of the smart card app.
13. The computer-implemented method according to claim 12, wherein: The volatile memory allocated during the installation of the smart card app is random access memory.
14. The computer-implemented method according to claim 13, wherein: When a context switch occurs from the smart card app after the object reference has been stored in the volatile memory, the object reference stored in the volatile memory is retained in the volatile memory so that it can be retrieved after the context switch returns to the smart card app.
15. The computer-implemented method according to claim 14, wherein: The memory allocation type keyword provided by the smart card app is a transient memory allocation type, the type of which is determined during the installation of the smart card app onto the smart card.
16. The computer-implemented method according to claim 15, wherein: When the memory allocation type keyword is not the transient memory allocation type, non-volatile memory is allocated from the smart card to store the object reference.
17. An object entity volatile memory allocation system, comprising: The object references the smart card mini-program's evaluation and allocation unit; as well as An object smart card app evaluation and allocation unit, wherein the object entity volatile memory allocation system utilizes the object reference smart card app evaluation and allocation unit to allocate volatile memory for the object reference during the installation of the smart card app, and the object entity volatile memory allocation system utilizes the object smart card app evaluation and allocation unit to allocate the volatile memory for the object during the runtime of the smart card app.
18. The object entity volatile memory allocation system according to claim 17, wherein: The Transient Allocation Object Reference Type keyword is used to allocate volatile memory for the object reference during the installation of the smart card app.
19. The object entity volatile memory allocation system according to claim 18, wherein: The transient allocation object type keyword is used to allocate the volatile memory for an object during the execution of the smart card app.
20. The object entity volatile memory allocation system according to claim 19, wherein: To determine whether the keyword in the smart card mini-program is a transient allocation object reference type keyword or a transient allocation object type keyword, the object entity volatile memory allocation system performs transient memory allocation object reference code evaluation and transient memory allocation object code evaluation of the smart card mini-program.