EP1050028A1 - Codelets - Google Patents

Codelets

Info

Publication number
EP1050028A1
EP1050028A1 EP99901065A EP99901065A EP1050028A1 EP 1050028 A1 EP1050028 A1 EP 1050028A1 EP 99901065 A EP99901065 A EP 99901065A EP 99901065 A EP99901065 A EP 99901065A EP 1050028 A1 EP1050028 A1 EP 1050028A1
Authority
EP
European Patent Office
Prior art keywords
application
memory
codelet
data
card
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP99901065A
Other languages
German (de)
French (fr)
Inventor
David Peacham
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mondex International Ltd
Original Assignee
Mondex International Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Mondex International Ltd filed Critical Mondex International Ltd
Publication of EP1050028A1 publication Critical patent/EP1050028A1/en
Withdrawn legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G07CHECKING-DEVICES
    • G07FCOIN-FREED OR LIKE APPARATUS
    • G07F7/00Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/355Personalisation of cards for use
    • G06Q20/3552Downloading or loading of personalisation data
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/30Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/357Cards having a plurality of specified features
    • G06Q20/3576Multiple memory zones on card

Definitions

  • Tins application relates to a system and method for improving the storage capacity and efficiency of memory management, in particular in an integrated circuit card, through the selective storage of programming inst ctions.
  • IC card typically is the size of a conventional IC card
  • ROM read-only memory
  • EEPROM electrically erasable programmable read-only-memory
  • I/O Input/Output
  • An IC card can be application specific or may contain multiple applications
  • .MULTOSTM is a multiple application operating system which runs on IC
  • terminal i.e., ATM and/or POS
  • the card is inserted for use.
  • IC c ⁇ ds typically have limited storage capacity due to the size and cost
  • Multi-application smart cards have their
  • MEL Multos Executable Language
  • MEL program instructions are read from EEPROM, an alterable memoiy, when they are >
  • the ROM on the IC card includes the operating system written in
  • the operating code stored in ROM is fixed when the ROM is
  • EEPROM becomes significant.
  • the size of a typical EEPROM on an IC card is
  • the size of an application program may be 3.3K for an electronic money
  • the application typically has data associated with the
  • operating system code requires 17.5K of the 24K of available memoiy in ROM.
  • ROM read only memory
  • EEPROM takes up six times more room on the chip than IK of ROM. As a result, it
  • the invention is directed to a system and method of efficiently storing
  • Codelets include programming instructions written
  • microprocessor based system accesses in order to execute the codelet.
  • codelet from the address table and execute the codelet's program instructions to perform
  • the codelet is written in a non-native programming language such as MEL
  • codelets can be used
  • microprocessors When the codelets are executed, they will act upon the data used by the codelets.
  • Figure 1 is a diagram of the memory of an IC card configured in
  • Figure 2 is a flowchart of the steps for performing a codelet query
  • Figure 3 is a block diagram of an IC card chip which can be used in
  • codelets can be stored in ROM so as to maximize the usage of memoiy and allow ROM
  • the codelet can be as small as one
  • the codelet is assigned a name and that name is placed in an address table
  • .Also present in ROM can be subroutines called primitives written in a
  • Codelets because they are written in the native language code. Codelets allow
  • Figure 1 shows an example of the memoiy configuration of ROM 101
  • ROM 101 includes operating system code 109 stored in native language
  • code (e.g., assembly language) which is run by the microprocessor to operate any
  • Codelets 113 are
  • codelets are called by another application or codelet.
  • the operating system will not call codelets
  • Program instruction sets called by the operating system are preferably primitives
  • Operating system data 115 is stored in EEPROM 105. This data is
  • space 119 has very few lines of code and calls the codelet B 121 which is stored in ROM
  • the data associated with application B is stored in the EEPROM because the data
  • a codelet address table 123 resides in EEPROM 105 as part of the operating system data.
  • codelet is a codelet address table 123 for ROM 101 for ROM 101 for
  • EEPROM 105 is described as a preferred embodiment of an
  • any other memory whose contents can be changed can also be used as
  • a codelet can be stored in EEPROM as well as in ROM, or any other
  • the codelet can be called by one - 10 - WO 99/38131 PCT/GB99/00209
  • a codelet is written in the application language
  • Codelets applicability are not restricted simply to IC cards, but can also be
  • Figure 2 is a flow chart of the steps for performing a query codelet. If an application needs to determine that a codelet has been stored on the IC card before it is called, it can execute a query codelet function. An exception to the general rule that codelets are written in an application programming language is the query codelet function, which is a series of program instructions that can be stored as a primitive. The query codelet function will check the address table stored in the memory of the IC card for the name of the codelet wliich is being checked. If the codelet name has been stored, then a flag indicator such as
  • Step 201 sets the variable codelet_id equal to the name of the requested
  • the name can be any combination of letters, numbers or
  • Step 203 then retrieves the
  • Step 205 sets the CCR Z flag to zero.
  • the CCR register is preferably used
  • the CCR register is used because it is very
  • the default response to a codelet query is negative indicating that the codelet has not been stored on the IC card.
  • the negative response is indicated by a zero value in the Z bit
  • Step 207 checks if the name stored in codeletjd is present in the codelet »
  • the Z flag remains set to zero in the negative state. If a match does not occur, the Z flag remains set to zero in the negative state. If a match does not occur, the Z flag remains set to zero in the negative state. If a match does not occur, the Z flag remains set to zero in the negative state. If a match does not occur, the Z flag remains set to zero in the negative state. If a match does not occur, the Z flag remains set to zero in the negative state. If a match does not occur, the Z flag remains set to zero in the negative state. If a match does not occur, the Z flag remains set to zero in the negative state. If a match does not occur, the Z flag remains set to zero in the negative state. If a match does not occur, the Z flag remains set to zero in the negative state. If a match does not occur, the Z flag remains set to zero in the negative state. If a match does not occur, the Z flag remains set to zero in the negative state. If a match does not occur, the Z flag remains set to zero in the negative state. If
  • This wild card feature can be used as
  • Step 209 then returns control of the processor to the application or other
  • codelet instructions executed if the codelet was found in the address table. If the codelet
  • the application can execute altemative instructions based on the
  • a call_codelet primitive can be used to pass control over
  • the codelet to be executed is identified by the specific codelet ID. If the request codelet ED is
  • a .specific known codelet address can be
  • codelet H is non-zero but does not appe.ar in the address table, then an abnormal end
  • the c- ⁇ l_codelet .function can be used, for example, to (1) pass control
  • control from a codelet to itself may be done for program memory management or
  • codelets utilize the program and data .stacks and the application .abstract .architecture
  • AAM Application Abstract Macliine arcliitecture.
  • the AAM .Architecture applies to .any pl ⁇ fo ⁇ n independent of its hardware and enables developers to write applications to store on the IC cards which are portable across many different types of
  • platfo ⁇ ns e.g., IC cards built by different manufacturers with different processor
  • AAM application abstract machine
  • Each application has a data memory space which is virtually allocated and
  • the program data address space is effectively divided into three segments: a Static
  • segments are logically mapped to the physical memory; they are virtual memory
  • the AAM data address space is preferably addressed and processed using seven different address registers and two
  • the operating system can
  • Codelets which can contain substantially all, or possibly
  • codele is called, codelets allow extra flexibility and efficiency in the operation of the IC
  • the pointers to the AAM data segments can be redirected when a codelet
  • codelet to perform its function on the applicable data and then return control to the
  • codelets are preferably stored in a read- - 16 -
  • codelets typically do not have their own variable data but instead use
  • Figure 3 shows an example of a block diagram of an integrated circuit 380
  • the integrated circuit chip is located on a chip on the card.
  • the IC chip preferably includes a
  • central processing unit 310 memory 320 including a RAM 326, a EEPROM 324, a ROM
  • Control logic 330 in the smart card provides sufficient sequencing and
  • CPU 310 in conjunction with control logic 330 can perform many different tasks
  • Some IC cards also include a
  • Input/output ports 350 are used for communication between the card and an interface
  • Timer 340 (which
  • Security circuitry 360 (which is optional) preferably includes .fusible
  • the Static memory space is preferably mapped to memory locations in
  • EEPROM 324 which are non- volatile.
  • the Dynamic memory space is preferably mapped
  • RAM 326 which is volatile memory.
  • EEPROM is identified as a preferred non-volatile memory
  • An operating system is preferably stored in ROM 322.
  • One or more codelets are also preferably stored in ROM 322.
  • EEPROM 324 EEPROM 324
  • IC cards are becoming increasingly used for many reasons.
  • IC card also called a smart card
  • IC card typically is
  • ROM read-only-memory
  • EEPROM electrically erasable programmable read-only memory
  • RAM random access memory
  • I/O Input/Output
  • card may contain a single application or may contain multiple independent applications in
  • MULTOSTM is a multiple application operating system which runs on IC
  • the multiple application operating system present on the IC card allows a card
  • a conventional single application IC card such as a telephone card or an
  • a telephone card could only be
  • the card 21 - A user would be required to carry multiple physical cards on ffl his oir r a her person, wvhsicchn would
  • a card user may have both a purse application and a credit/debit
  • the present invention provides for a multiple application architecture for
  • a M application abstract machine
  • a data memory space including at least
  • Additional delegation commands can be issued by the second application
  • the command delegated is interpreted by a delegated application in the same manner as a selection command being issued directly by a terminal and therefore each application performs the security functions at the same level
  • the volatile memory segment can further be separated into public
  • the Dynamic memory region can be used solely as temporary work space for
  • Fig. 1 is block diagram illustrating the data memory space segment
  • Fig. 2 is a block diagram illustrating the code memory and the data
  • Fig. 3 is a flow diagram illustrating the steps of performing a request for a
  • Fig. 4 is a flow diagram illustrating the steps of perfo ⁇ ning a return
  • Fig. 5 is a flow diagram illustrating the steps of performing an inquire
  • Fig. 6 is a block diagram of an IC card chip which can be used as a
  • FIGS. 7A, 7B and 7C illustrate multiple delegation calls made between
  • the present invention provides for a method and apparatus for processing multiple application programs with associated data stored on an IC card which can be accessed and executed.
  • An application stored on the card can be selected by a terming, or other interface device, or another application.
  • processor located on the IC card) and the associated data which the application stores and uses during execution of the program.
  • a multi-application card may store a purse application, or an
  • Each application has software code and associated data to support the execution of that software code.
  • Each application is allocated a memory space when
  • purse application need not be aware of the specific loyalty program stored on the card, but instead may contain an instruction to communicate with any loyalty progr.am stored
  • the loyalty program will require input data representative of the amount of
  • transferred data may be
  • te current invention which is described in greater detail below, is to selective
  • AAM Application Abstract Machine
  • AAM application abs f rac. machine
  • Each application has a data memory space which is virtually allocated and
  • the program data address space is effectively divided into three segments: a Static
  • the AAM data address space is preferably addressed and
  • Figure 1 shows an illustrative diagram of a logical data space allocation
  • data portion 101 includes a Static data space 103, a Public data space 105 and a Dynamic
  • address registers can contain physical memory addresses but preferably contain offset
  • the overall address space is 64K bytes, although the size varies with the applicable platform and the available memory size.
  • the registers can also be considered
  • pointers or can be any other conventional addressing mechanism.
  • memory is non-volatile which is not erased after power is removed from the IC card (such as EEPROM), the Dynamic space is volatile (such as RAM) which may be erased
  • An IC card can receive power from a terminal after it is interfaced into the terminal.
  • an IC card may contain a battery to maintain some power for memory and
  • volatile memory will typically be erased after the IC card is removed from its
  • the def i ned AAM data space has bytes in each segment which are
  • the segment address of the fust byte of the Static segment is zero, so that d i e
  • segment address of a given location within the Static region is equal to its offset. - 29 r- ⁇ -..ir: P f 1
  • Pointers to other specific regions of the Static data area can be stored in
  • the Static data because the Static region is non- volatile. For example, if the card user's
  • Public segments is not always equal to a particular offset from the beginning of the
  • the fourth location in the Dynamic segment will be different for each operation
  • MEL Executable Language
  • a tagged address preferably is used to
  • a tagged address is a nineteen bit value consisting of a three bit tag
  • Each of the seven address registers for - 3o - 'S. * nny ⁇ - ' ⁇ y- ⁇ um ' -' ' ⁇ the AAM data space contain a segment physical address. For " Tnsta ⁇ cer
  • registers SB 109 and ST 111 point to the boundaries of the Static, the address registers
  • PB 113 and PT 115 point to the boundaries of the Public and the address registers DB
  • register points to the byte immediately after the last valid byte. For example, the last
  • Register LB functions as a stack frame pointer. It
  • the allocated Static segment 103 contains the
  • Static data includes data which is associated with each
  • Static data also includes variable data which is stored for use in future
  • the Static data is addressed using register SB (Static Base) and the
  • register ST (Static Top) as offset registers. These registers contain the offset value from a
  • SB is defined as zero
  • the Static segment is preferably mapped
  • EEPROM Electrical Erasable Programmable Read-Only Memory
  • the Dynamic segment 107 contains the application's volatile or temporary
  • Dynamic data includes data which is temporarily used during the execution of an
  • a purse application may temporarily store the value of a transaction in order to
  • Dynamic segment preferably is divided into two parts, the session data portion and the
  • the size of the session data is a constant for each application and is
  • the stack data portion stores data in a last-
  • the stack is initially empty, but expands and contracts during
  • the Dynamic data is addressed from the register DB 117 to register DT
  • Register LB 119 serves as a local stack frame pointer to particular memory
  • Register LB LB
  • Register DT 121 serves as an address offset for the stack pointer.
  • That application also contains the application's session data which is used in performing
  • the session data is set to zero upon the start of the execution of
  • Stack data will be saved in the stack if the application delegates a task or
  • a delegation function occurs when one application selects another
  • the delegator calls the Delegate primitive.
  • primitive is a subroutine recognized by the multiple application operating system which - 33 - fl ⁇ ( is executed when the operating system interprets the Delegate instruction. Primitives can
  • delegated application then generates its own data memory space according to the AAM
  • the Dynamic memory space is also shared
  • the delegated application is executed because the Dynamic data is secret.
  • delegated application has finished processing the command, and has written a response
  • Delegate primitive The response generated by the delegated application is retrieved or
  • the delegator application may simply - 34 - _ Y exit in turn, thus sending the response to the IFD, or may cany out further processing
  • command can delegate the function B to application A in order to reduce the need for
  • an application stored on the card can delegate the "retrieve
  • PIN function to a PIN application which returns a stored universal PIN for the card.
  • a new session begins whenever the IFD, e.g. a terminal,
  • the delegated application treats the delegate function as if the IFD
  • application A is selected by an IFD device, and receives commands X, Y and Z from the
  • application A may delegate all three commands to application B. For example,
  • delegations may occur in response to delegation comma. nds in the program code. Both
  • application A is selected, and receives commands X,
  • Application A will have its session and stack data initialized when it
  • One example of a use of session data is to support the use of a session
  • the application could reserve one byte of session
  • selected delegated application could update the flag as follows: if the PIN command is
  • the PIN checking function could be a delegated function from the selected application to a PIN checking application.
  • the Public segment 105 is used for command and response data being
  • segment contains the data passed between two applications, the delegator (the application
  • An application may also use the Public segment as a further application
  • register PB 113 stored in register PB 113 as a starting address, to register PT 115 as an ending address.
  • Register PB 113 and Register PT 115 are fixed for the duration of a command-response
  • Public data can include data inputted into or
  • a terminal such as a transaction amount, vendor identification data, terminal
  • Public data can also include data which is to be transmitted to an IFD
  • the multiple application operating system ensures that the data stored in
  • the Public segment remains private to the application until the application exits or
  • the data in the Public segment is then made available to other - 37 - entities as follows: (1) if the application delegates, th lee wwhhoollee ooff t thhee PPuubblliicc sseeggmmeenntt
  • segment containing the I/O response parameters and data are made available to the IFD.
  • the operating system on the IC card preferably overwrites
  • MCD MULTOS carrier device
  • a portion of the Public memory segment is also used as a communications
  • the I/O protocol data and parameters are preferably stored at the top of the Public Switches.
  • FIG. 1 shows an extended illustration of the AAM implemented
  • Data memory space 201 includes the three segments Static, Public and
  • Code memory space 203 contains the program
  • the application instructions are
  • Instruction 205 is stored at
  • AAM architecture A code pointer (CP) register 207 indicates the particular code
  • the register indicates, e.g., through an offset
  • Register 209 contains eight bits, four of which are for use by the individual application
  • condition codes can be used by conditional instructions such as
  • condition codes can include a carry bit, an overflow bit, a
  • SB When the application is loaded, SB is set to zero and ST is equal to the number of bytes in the application's Static database.
  • the other address registers are initialized when the
  • CP 207 is set to zero and all eight bits in CCR 209 are
  • a communications interface mechanism is present between the IFD and an
  • a command-response parameter means an application is given a command to perform and returns a response to the entity issuing the
  • the delegation can be directly in response to a received command
  • the delegator acts as a controller for delegating commands or subcommands to
  • the delegated command can be embedded
  • Figure 3 shows a flow chart of the steps which are performed when a
  • Step 301 sets the parameter named delegator_application_id
  • ID indicates the current application which is selected and which is currently being
  • the delegator ID indicates the application which delegates a function to
  • Step 303 then pushes (stores) the
  • delegator ID onto the top of the delegate_id_stack (delegate stack).
  • the delegate stack is preferably stored outside of an application's AAM
  • the delegate stack preferably operates in a LIFO
  • Step 305 sets the selected ID to the delegate_request.delegate_
  • Step 307 sets the application_command parameter to the value stored in
  • the delegator application can choose which
  • Step 309 then sends the application_command to the AAM operating system for execution by the delegatee
  • the delegator application is then suspended (or interrupted). . Any data that
  • Figure 4 is a flow chart of the steps for performing a "return delegation
  • Step 401 gets application_responses from the Public memory space of the delegated
  • the response data is passed in the Public memory segment of the delegatee AAM.
  • Step 403 sets the delegate_response. status variable to a success condition.
  • This - 42 ANNEX ⁇ l TO THE DESCRIPTION means that a delegation operation has been successfully completed.
  • Step 405 sets the delegate , response.application_responses parameter to the application_responses values
  • Step 407 sets the delegate_response.delegate_application_id parameter to
  • Step 409 pops the top (i.e.,
  • delegate_application_id from the delegate_id_stack. This information indicates the identity of the delegator application for
  • Step 411 sets the select_file.application_id value to the delegator_application_id value.
  • the Dynamic data for the delegator application will be retrieved for the delegator application from its stored location so that the application will continue to execute where it left off with all data intact but will also
  • step 413 the .5 delegate_response data is sent to the current application for further processing.
  • response data is passed through the Public data space which could be the same physical RAM memory location because all applications share the physical volatile memory space.
  • Figure 5 shows a flow chart of the steps involved for inquiring about a
  • delegator ID when a delegate command is received by a delegated application.
  • 2 o delegated application may need to know the identity of the delegator because it may
  • an - 43 - fi i r.7 airline loyalty program may need to l now if awarded frequent flyers will be based on
  • Step 501 receives the delegator_id_enq_request from the AAM operating
  • Step 503 checks if
  • the delegate_id_stack is empty. If the stack is empty, then no delegation operations have
  • step 511 sets the
  • Step 513 sets the
  • delegator_is_enq_request.error_cause a value indicating "no delegator
  • step 505 sets the delegator_id_enq_response.status parameter to a
  • Step 507 sets the delegator_id_enq_response.delegator_
  • the stored data at the top of the stack indicates
  • Step 509 then sends the I f. L'.-' ⁇ i.' m
  • Figure 6 shows an example of a block diagram of an integrated circuit
  • the integrated circuit chip is located on a chip on the card.
  • the IC chip preferably includes a
  • central processing unit 601 a RAM 603, a EEPROM 605, a ROM 607, a timer 609,
  • control logic 611 I/O ports 613 and security circuitry 615, which are connected together
  • Control logic 611 in the smart card provides sufficient sequencing and
  • CPU 601 in conjunction with control logic 611 can perform many different tasks
  • Some IC cards also include a
  • Input/output ports 613 are used for communication between the card and an IFD which
  • Timer 609 (which generates and/or provides a
  • clock pulse drives the control logic 611, CPU 601 and other components requiring a
  • o circuitry 615 (wliich is optional) preferably includes fusible links that connect the
  • EEPROM 605 which is non ⁇ volatile.
  • Dynamic memory space is preferably mapped to RAM 603 which is
  • the Public memory space is also preferably
  • RAM 603 which is volatile memory.
  • RAM 603 RAM is identified as a preferred non ⁇
  • volatile memory and EEPROM is identified as a preferred volatile memory. Other types of memory could also be used with the same characteristics.
  • Figures 7A, 7B and 7C illustrate an example of a delegation function being performed in order to process multiple applications on an IC card.
  • a delegation function 702 is
  • FIG. 7A Also shown in Figure 7A is an empty delegator ID stack 705. Since the stack is empty, there is no data associated with it and it is shown only for illustrative purposes.
  • the multiple application operating system receives the delegate command
  • microprocessor and other circuitry on the card will process the instructions and allocate
  • the delegator ID 707 is placed on top of the stack 705.
  • delegate function 711 is called to delegate the operation to the third application.
  • the multiple application operating system receives the delegate command
  • the delegator ID 713 of the second application is
  • delegator ID at the top of the stack is popped to indicate that execution of the second
  • Additional applications can be managed by the delegator ID stack in a
  • -An integrated circuit card comprising: a microprocessor; a volatile memory coupled to said
  • microprocessor a non-volatile memory coupled to said microprocessor; and a plurality of
  • said microprocessor allocates for each said executing application an
  • associated data memory space comprising at least a volatile memory segment for
  • a public region is divided into at least two regions, including a public region and a dynamic region.
  • ⁇ 2 is divided into at least two regions, including a public region and a dynamic region.
  • volatile segment includes a public and dynamic portion.
  • single integrated circuit card comprising: means for allocating a data space comprising at least a non-volatile
  • volatile memory segment is divided into at least two regions, including a public region
  • ⁇ 2 is divided into at least two regions, including a public region and a dynamic region.
  • 4 application's volatile memory segment includes a public and dynamic portion.
  • each application has an associated identifier; a data stack accessible by said databus for storing said applications'
  • processor means for executing instructions from said application programs
  • said processor means allocates a data memory space for said application which is
  • volatile memory volatile memory and at least one address in said volatile memory; and wherein said processor means interrupts said first application at least once
  • data memory space comprises at least a volatile
  • non-volatile memory segment for referencing static data stored in said non-volatile
  • 2 memory segment is divided into at least two regions, including a public region and a
  • application's volatile memory segment includes a public and dynamic portion.
  • An integrated circuit card comprising:
  • data memory space comprises at least a volatile memory segment for referencing
  • the integrated circuit card of claim 51 further including means for storing
  • the integrated circuit card of claim 53 further including means for
  • volatile memory segment is divided into at least two regions, including a public region
  • volatile segment is divided into at least two regions, including a public region and a
  • a multi-application IC card which processes two or more applications
  • the AAM architecture only allows
  • one application to be executed at a time and allows for shared processing by performing a
  • the data space includes a volatile and
  • the delegation function temporarily interrupts the execution of the
  • the first application then retrieves the saved data and completes its
  • a delegator stack is used to keep track of the delegator' s identity when
  • the AAM model allows for a high level of security while

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Accounting & Taxation (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Stored Programmes (AREA)
  • Control Of Vending Devices And Auxiliary Devices For Vending Devices (AREA)

Abstract

A system and method for efficiently storing programming instructions in a microprocessor based system where codelets which includes program instructions written in a non-native programming language (such as MEL or C) are stored in a read only portion of memory. The location of the codelets are stored in an address table which is accessed by an operating system when an application calls the codelets during execution. At that time, the microprocessor accesses the codelet instructions until the codelet function is complete. By storing codelets in read only memory which is cheaper and takes up much less physical space than alterable memory (such as EEPROM), more programming instructions can be stored in the same amount of physical space. Additionally, since codelets are written in non-native programming languages, they become platform independent since they can be compiled by different compilers to run on any platform.

Description

CODELETS
SPECIFICATION
PRIORITY APPLICATION
This application claims priority to United States Provisional application
60/072,561 filed on January 22, 1998, and entitled "CODELETS", which is hereby
incorporated by reference.
RELATED APPLICATION
This application is related to United States application No. 09/064,915
filed on April 23, 1998, entitled "MULTI-APPLICATION IC CARD WITH
DELEGATE FEATURE" and assigned to Mondex International Limited, wliich is hereby
incorporated as Annex A. FIELD OF INVENTION
Tins application relates to a system and method for improving the storage capacity and efficiency of memory management, in particular in an integrated circuit card, through the selective storage of programming inst ctions.
BACKGROUND OF INVENTION
.Integrated circuit (IC) cards are becoming increasingly used for many
different purposes in the world today. .An IC card typically is the size of a conventional
credit card which contains a computer chip including a microprocessor, read-only-
memory (ROM), electrically erasable programmable read-only-memory (EEPROM), an
Input/Output (I/O) mechanism and other circuitry to support the microprocessor in its
operations. An IC card can be application specific or may contain multiple applications
in memoiy. .MULTOS™ is a multiple application operating system which runs on IC
cards, among other platforms, and allows multiple applications to be executed on the card
itself. This allows a card user to run many programs stored in the card (for example,
credit/debit, electronic money/purse and/or loyalty applications) irrespective of the type
of terminal (i.e., ATM and/or POS) in which the card is inserted for use.
IC c^ds typically have limited storage capacity due to the size and cost
restraints of locating memory on the card. Multi-application smart cards have their
applications written in a programming l.anguage that are typically stored in the EEPROM whose contents can be changed during the lifetime of the card. One example of a
programming language used in IC cards is Multos Executable Language (MEL). The
MEL program instructions are read from EEPROM, an alterable memoiy, when they are>
executed and are interpreted by the operating system stored in ROM.
The ROM on the IC card includes the operating system written in
assembly language code for the particular integrated circuit configuration (native
language type code). The operating code stored in ROM is fixed when the ROM is
initially written and the information stored in ROM will not change for the life of the
card.
One of the concerns with multi-application IC cards is that when
attempting to store multiple applications on the card, the memory constraints of the
EEPROM becomes significant. Currently, the size of a typical EEPROM on an IC card is
8K bytes. The size of an application program may be 3.3K for an electronic money
(purse) application. Moreover, the application typically has data associated with the
code, which could be about 3K bytes of memoiy for an electronic money application.
Therefore, the application including the code and the data typically requires 6.6K of
memoiy .space. I addition, the operating system requires data to be stored in EEPROM,
which data is used during the operation of the operating system. This overhead
requirement is generally about IK of space in EEPROM. Consequently, if a purse
application is stored in EEPROM, 7.6K of memory will be needed, leaving only .4K of EEPROM available for a second application. This is not an acceptable option for an
efficient and effective multi-application IC card system.
With regard to memory space in ROM, a typical multiple application
operating system code requires 17.5K of the 24K of available memoiy in ROM.
Therefore, 6.5K of ROM is unused and can never be used after the card is distributed to
the public because ROM can only be configured once. Moreover, ROM memory is
approximately six times more dense than EEPROM memoiy, meaning that IK of
EEPROM takes up six times more room on the chip than IK of ROM. As a result, it
would be advantageous to (1) folly utilize any unused memory space in ROM and (2) use
as much ROM as possible instead of EEPROM to minimize the size of memory on the
integrated circuit in the card.
SUMMARY OF THE INVENTION
The invention is directed to a system and method of efficiently storing
programming instructions in a microprocessor based system with memory size and/or
cost constraints, such as an IC card. Codelets include programming instructions written
in non-native code and are stored in a read-only portion of memory. The memory address
of the codelet is stored in an address table which the operating system for the
microprocessor based system accesses in order to execute the codelet. An application
residing in the alterable portion of memory will call the codelet to be executed with a program instruction, and the operating system will look up the memory .address of the
codelet from the address table and execute the codelet's program instructions to perform
its designated function. By storing the codelet in read-only memory, the program.ming
instructions are stored in a memory which is cheaper and physically smaller than alterable
memory so more overall progr- -ming instructions can be stored in the overall memoiy
.system. Additionally any extra space in the read-only memory can be fully utilized by
using the codelets.
The codelet is written in a non-native programming language such as MEL
or C so that the instructions will be interpreted by the operating system in order to
execute them. This allows different platforms to use the same codelet because each
operating system will convert the non-native programming instructions to machine
readable instructions for the particular microprocessor. Thus the codelets can be used
with different types of platfoπns without the need to translate the instructions for specific
microprocessors. When the codelets are executed, they will act upon the data used by the
application which accessed the codelet in a preferred embodiment.
BRIEF DESCRIPTION OF THE DRAWINGS
Further objects, features and advantages of the invention will become
apparent from the following detailed description taken in conjunction with the
accompanying figures showing illustrative embodiments of the invention, in which - 6 -
Figure 1 is a diagram of the memory of an IC card configured in
accordance with an embodiment of the invention;
Figure 2 is a flowchart of the steps for performing a codelet query; and
Figure 3 is a block diagram of an IC card chip which can be used in
accordance with an embodiment of the invention.
Throughout the figures, the same reference numerals and characters,
unless otherwise stated, are used to denote like features, elements, components or
portions of the illustrated embodiments. Moreover, while the subject invention will now
be described in detail with reference to the figures, it is done so in connection with, and by way of example of, the illustrative embodiments. It is intended that changes and modifications can be made to the described embodiments without departing from the true scope and spirit of the subject invention as defined by the appended claims.
DETAILED DESCRIPTION OF THF INVENTION
Greater and fuller utilization of ROM and efficient overall use of memoiy is accomplished through the use of "codelets," which are sets of
.instructions written in a programming language (not native language code). These
codelets can be stored in ROM so as to maximize the usage of memoiy and allow ROM
to store complete applications as well as primitives. The codelet can be as small as one
instruction or as large as will fit into the remaining ROM memory space. For example, WO 99/38131 _ - _ PCT/GB99/00209
the purse application described in the background can be stored in ROM when the card is
initialized in order to free up space in EEPROM, the alterable memory, for additional
applications which can be loaded at any time.
The codelet is assigned a name and that name is placed in an address table
stored in EEPROM. When a codelet is called by another application, the address table
gives the location of the firet instruction in the codelet stored in ROM and each
instruction is executed just as if the application were stored in EEPROM.
.Also present in ROM can be subroutines called primitives written in a
native language code for the microprocessor which C be called by either the operating
system itself or by applications when they are executed. Primitives are written in the
native language (i.e. assembler language) so that they can be executed very quicky and
minimal interpretation of the instructions is necessary for execution. These primitives are
collections of instructions which typically perform a desired function, such as a
mathematical .function. The instructions are never changed during the lifetime of the
card. Any data used or accessed by the primitives .are stored in EEPROM so that the
contents of the data elements can change as necessary. Primitives axe different than
codelets because they are written in the native language code. Codelets allow
programmers to use an easier and more programmer friendly programming language such
as .MEL or "C." Programming l.anguages also allow programmers to do advanced
features which may be hard to directly implement in an assembler native language. Figure 1 shows an example of the memoiy configuration of ROM 101
(indicated by label 103) and of EEPROM 105 (indicated by label 107) which .are located
on an IC card. ROM 101 includes operating system code 109 stored in native language
code (e.g., assembly language) which is run by the microprocessor to operate any
application and perform card functions. Also stored in ROM are primitives 111 which
are sets of instructions stored in the native language code on ROM and which are called
by the operating system and/or an application being nm on the card. Codelets 113 are
sets of instructions stored in a programming language form (e.g., in MEL) in ROM which
are called by another application or codelet. The operating system will not call codelets
directly as part of the operating code because of the high speed required by the operating
system. Program instruction sets called by the operating system are preferably primitives
written in the native language codes.
Operating system data 115 is stored in EEPROM 105. This data is
necessary for the operation of the operating system .and is unavailable for applications to
utilize. Application A space 117 comprising program code and data is entirely stored on
EEPROM 105 and takes up most of the available space in the memory. Application B
space 119 has very few lines of code and calls the codelet B 121 which is stored in ROM
101. The data associated with application B is stored in the EEPROM because the data
may change. This configuration allows multiple applications to reside in EEPROM
memory 105 by storing large blocks of code in ROM and calling the codelet instructions. A codelet address table 123 resides in EEPROM 105 as part of the operating system data.
This allows the operating system to locate the codelet when an application calls the
codelet. -Alternatively, the codelet address table 123 could reside in ROM 101 for
addresses .known when the card is first manufactured.
While EEPROM 105 is described as a preferred embodiment of an
alterable memory, any other memory whose contents can be changed can also be used as
an alterable memory.
-As memory storage capabilities of EEPROM get larger with time, memory
management will continue to be an important concern because more and more
applications will be available on the card. Thus, a user of the card may choose different
combinations of purse applications, credit/debit applications, loyalty programs such as
frequent flyer reward programs, health information programs or catalog ordering
programs. Each application will require a finite amount of space on the card and codelets
will help utilize available memory space efficiently.
A codelet can be stored in EEPROM as well as in ROM, or any other
memory area which can be addressed by the card. This includes additional EEPROMs if
present or even external memory units which are accessible by the card. Codelets could
also contain discrete portions of programs so that part of a program will reside in
EEPROM and part of a program as a codelet on ROM. The codelet can be called by one - 10 - WO 99/38131 PCT/GB99/00209
or more applications which are executed. A codelet is written in the application language
(e.g. MEL) and is considered part of the program no matter where it resides.
Applications written in an application language will preferably run on a
number of different platforms (i.e. different integrated circuits made by different
manufacturers or different integrated circuit models made by the same manufacturer). It
is desirable to have an application written once and allow the particular IC card to
compile the application code to run the code. A primitive is written in native language
code which is specific to the platform it resides on. A primitive for one platform will not
nm on the platform of a different manufacturer. Codelets transcend the limitations of a
.specific platform by being written in a program language which can be stored on any
platform without lengthy pre-processing or without having to rewrite the code to fit the
platform.
Codelets applicability are not restricted simply to IC cards, but can also be
used in other microprocessor systems with memory constraints such as a computer watch
or other item containing a processor.
Figure 2 is a flow chart of the steps for performing a query codelet. If an application needs to determine that a codelet has been stored on the IC card before it is called, it can execute a query codelet function. An exception to the general rule that codelets are written in an application programming language is the query codelet function, which is a series of program instructions that can be stored as a primitive. The query codelet function will check the address table stored in the memory of the IC card for the name of the codelet wliich is being checked. If the codelet name has been stored, then a flag indicator such as
the zero (Z) flag of a conventional Condition Code Register (CCR) is set to one
(indicating a positive response) and the application can then successfully call the codelet'
which has just been checked, ff the name of the codelet is not present in the address
table, then a zero will be placed in the Z flag (indicating a negative response) and the
application will not call the codelet to avoid an execution error and/or an abnormal end to
the execution of the application.
Step 201 sets the variable codelet_id equal to the name of the requested
codelet to be checked. The name can be any combination of letters, numbers or
characters which identify the codelet. If the requested codelet name is zero, a
predetermined wild card, then a match to a codelet name in the address table is always
made and the Z flag is always set to one (a positive response). Step 203 then retrieves the
address table from the memory of the IC card and in particul.ar the portion containing the
addresses of any stored codelets.
Step 205 sets the CCR Z flag to zero. The CCR register is preferably used
as a mechanism to relay the answer to the codelet query to the application or other
program instructions requesting the query. The CCR register is used because it is very
fast and enables the requesting application to determine the outcome of the request
without transferring data or looking up .further variables in designated memory areas.
The default response to a codelet query is negative indicating that the codelet has not been stored on the IC card. The negative response is indicated by a zero value in the Z bit
of the CCR register.
Step 207 checks if the name stored in codeletjd is present in the codelet »
address table, and if it is the Z flag in the CCR register is set to a positive state. A
comparison is made of the codeletjd variable to the names of codelets in the address
tables. If a match does not occur, the Z flag remains set to zero in the negative state. If a
match occurs, then the codelet has already been stored and its name properly placed in the
address table so the Z flag is set to a positive state, i.e. one. If codelet_ id is set to a value
of zero, then an automatic match is recorded. This wild card feature can be used as
needed by the programmer.
Step 209 then returns control of the processor to the application or other
instruction set which inquired about the status of the codelet. The application can then
successfully pass control of the microprocessor to the codelet instructions and have the
codelet instructions executed if the codelet was found in the address table. If the codelet
name was not found, the application can execute altemative instructions based on the
negative result of the codelet check. The application developer can program for both
alternatives.
Additional operational primitives besides query_ codelet can also be used
in connection with codelets. A call_codelet primitive can be used to pass control over
from the application to the codelet called in order to execute the codelet instructions. The codelet to be executed is identified by the specific codelet ID. If the request codelet ED is
set to zero a predetermined special value, then a .specific known codelet address can be
used to identify and execute the codelet outside of the address table. If the codeletjd is
not zero, then the address for the codelet is looked up on the address table and that
address is used to locate the start of the program instructions for the codelet. If the
codelet H) is non-zero but does not appe.ar in the address table, then an abnormal end
occurs. However, this error can be avoided by performing a query_codelet .function as
described above.
The c-ύl_codelet .function can be used, for example, to (1) pass control
from an application to a codelet; (2) pass control from one codelet to -mother; or (3) pass
control from a codelet to itself (wMch may be done for program memory management or
other iterative programming re^ons). The codelet acts on the data segment of the calling
application and preferably has no data of its own. This ensures that there is no possibility
of data leakage between .applications and keeps the data secure and uncorrupted. The
codelets utilize the program and data .stacks and the application .abstract .architecture
machine as described in United States application No. 09/064,915 entitled "Multi-
Application IC Card With Delegate Feature" which has been incorporated by reference. An efficient .architecture for processing multi applications in an IC card is
termed an Application Abstract Macliine (.AAM) arcliitecture. The AAM .Architecture applies to .any pl^foπn independent of its hardware and enables developers to write applications to store on the IC cards which are portable across many different types of
platfoπns (e.g., IC cards built by different manufacturers with different processor
configurations) without the need for .knowledge about the specific hardware of the
platform.
An application abstract machine (AAM), a teπn for the memory allocation
and organization for the data stored and used by each application, is created for each
application stored on the IC card which is executed by the processor on the card. In order
to ensure data integrity and security when data is transfeired between applications which
are executed on the IC card, only one application on the IC card is allowed to be executed
at a time. Each application has a data memory space which is virtually allocated and
mapped onto the physical memory addresses available in the IC card memories. Data is
then passed between two or more applications within a specified memory location and in
a manner consistent with transferring data to an external teπninal or device with which
the IC card is securely interacting. At a general level, each .AAM space created for each
application being executed includes two separate address spaces, one for the program
code itself and one for the program data which is stored .and/or used by the application.
The program data address space is effectively divided into three segments: a Static
segment, a Dynamic segment and a Public segment. The Static, Dynamic and Public
segments are logically mapped to the physical memory; they are virtual memory
segments as opposed to physical memoiy segments. The AAM data address space is preferably addressed and processed using seven different address registers and two
control registers.
In a multi-application operating system, the operating system can
configure each application to have its own logical address space. Each application
therefore operates independently and if one application calls another application, the
communication will follow procedures simile to tallάng to a terminal. This type of
configuration ensures the integrity of the logical address space and enhances security of
data flow between applications. Codelets, which can contain substantially all, or possibly
all, of the instruction lines of the code, .are written in the application language. By calling
a codelet, the logical space for OT application is maintained and the application
instructions are simply located in a more efficient memoiy location. Moreover, because
the I/O like parameters which are required between applications are not invoked when the
codele. is called, codelets allow extra flexibility and efficiency in the operation of the IC
card.
The pointers to the AAM data segments can be redirected when a codelet
is called. Thus, where a codelet is stored in EEPROM, the static segment of the memory
of the AAM will be made up of the codelet instructions while the dynamic segment of
memoiy will still be that of the original application calling the codelet. This allows the
codelet to perform its function on the applicable data and then return control to the
application when it is complete. Because the codelets are preferably stored in a read- - 16 -
only type memoiy, codelets typically do not have their own variable data but instead use
the data from the application in a secure manner.
When control of the IC card processing switches from an application or
other codelet to the codelet called, it is important that the operating system know the
correct address of the codelet program instructions. Although the address of the codelet
is stored in the address table, an additional check can be performed by setting OT upper
boundary so that the fetched instructions of the codelet by the operating system will be
from a valid memory location. This primitive is called set_code_boundaries.
Figure 3 shows an example of a block diagram of an integrated circuit 380
located on an IC card chip which can be used in conjunction with the invention. The
integrated circuit chip is located on a chip on the card. The IC chip preferably includes a
central processing unit 310, memory 320 including a RAM 326, a EEPROM 324, a ROM
322, a timer 340, control logic 330, I/O ports 350 and security circuitry 360, which are
connected together by a conventional data bus 390 or other conventional means.
Control logic 330 in the smart card provides sufficient sequencing and
switching to handle read-write access to the card's memory through the input/output ports
350. CPU 310 in conjunction with control logic 330 can perform many different
functions including performing calculations, accessing memory locations, modifying
memory contents, and managing input/output ports. Some IC cards also include a
coprocessor 370 for handling complex computations like cryptographic algorithms. Input/output ports 350 are used for communication between the card and an interface
device (IFD) which transfers information to and from the card. Timer 340 (which
generates and/or provides a clock pulse) drives the control logic 330, CPU 310 and other
components requiring a clock signal through the sequence of steps that accomplish
functions including memory access, memory reading and/or writing, processing, and data
communication. Security circuitry 360 (which is optional) preferably includes .fusible
links that connect the input/output lines to internal circuitry as required for testing during
manufacture, but which are destroyed upon completion of testing to prevent later access.
The Static memory space is preferably mapped to memory locations in
EEPROM 324 which are non- volatile. The Dynamic memory space is preferably mapped
to .RAM 326 which is volatile memory which has quick access. The Public memory
space is also preferably mapped to RAM 326 which is volatile memory. The Dynamic
data and Public data will be stored in different portions of RAM 326, wliile ROM is
identified as a preferred non-volatile memory and EEPROM is identified as a preferred
non- volatile, alterable memoiy. An operating system is preferably stored in ROM 322.
One or more codelets are also preferably stored in ROM 322. The address table and one
or more applications and codelets are preferably stored in EEPROM 324. Other types of
memory could also be used with the same characteristics.
The foregoing merely illustrates the principles of the invention. It will
thus be appreciated that those sltilled in the art will be able to devise numerous systems and methods which, although not explicitly shown or described herein, embody the
principles of the invention and are thus within the spirit and scope of the invention.
The scope of the present disclosure includes any novel feature or combination of features disclosed therein either explicitly or implicitly or any generalisation thereof irrespective of whether or not it relates to the claimed invention or mitigates any or all of the problems addressed by the present invention. The applicant hereby gives notice that new claims may be fonnulated to such features during the prosecution of this application or of any such further application derived therefrom. In particular, with reference to the appended claims, features from dependent claims may be combined with those of the independent claims and features from respective independent claims may be combined in any appropriate manner and not merely in the specific combinations enumerated in the claims.
- 19 -
ANNEX A TO THE DESCRIPTION
BAKER & BOTTS LLP
30 ROCKEFELLER PLAZA
NEW YORK, NEW YORK 10112
TO .ALL WHOM IT MAY CONCERN:
Be it .known that WE, DAVID BARRINGTON EVERETT, STU.ART JAMES MILLER, ANTHONY DAVID PEACHAM, IAN STEPHENS SIMMONS, TIMOTHY PHILIP RICH.ARDS and JOHN CHARLES VINER, citizens of GREAT BRIT.AIN, whose post office addresses are 31 Ashdown Avenue, Saltdean, Brighton, East Sussex BN2 8AH; 9 Woodford Green, The Warren, Bracknell, Berks RG12 9YQ; 4 Lynwood, Groombridge, Tunbridge Wells, Kent TN3 9LX; The Elms, School Road, Broughton, Cambs PE17 3AT; 32 Craig Mount, Radlett, Herts WD7 7LW; and Hydes, Woodlands Lane, Windlesham; respectively, have invented an improvement in
MULTI-.APPLICATION IC CARD WITH DELEGATION FEATURE
of which the following is a
SPECIFICATION
PRIORITY APPLICATIONS
This application claims priority to United States Provisional Application 60/046,514 filed on May 15, 1997, entitled "Design for a Multi Application Smart Card" and United States Provisional application 60/046,543 filed on May 15, 1997, entitled "Virtual Machine for a Multi Application Smart Card". - 20 - m n s iii'StoRiriiϋ Aii
BACK GROUND OF INVENTION
Integrated circuit ("IC") cards are becoming increasingly used for many
different purposes in the world today. .An IC card (also called a smart card) typically is
the size of a conventional credit card which contains a computer chip including a
microprocessor, read-only-memory (ROM), electrically erasable programmable read¬
only-memory (EEPROM), a random access memory (RAM), an Input/Output (I/O)
mechanism and other circuitry to support the microprocessor in its operations. An IC
card may contain a single application or may contain multiple independent applications in
its memory. MULTOS™ is a multiple application operating system which runs on IC
cards, among other platforms, and allows multiple applications to be executed on the card
itself. The multiple application operating system present on the IC card allows a card
user to run many programs stored in the card (for example, credit/debit, electronic
money/purse and/or loyalty applications) irrespective of the type of terminal (i.e., ATM,
telephone and or POS) in which the card is inserted for use.
A conventional single application IC card, such as a telephone card or an
electronic cash card, is loaded with a single application card and only executes that one
application when inserted into a terminal. For example, a telephone card could only be
used to charge a telephone call and could not be used as a credit/debit card. If a card user
desires a variety of application functions to be performed by single application IC cards
issued to him or her, such as both an electronic purse and a credit/debit function, the card 21 - A user would be required to carry multiple physical cards on ffl his oir r a her person, wvhsicchn would
be quite cumbersome and inconvenient. If an application developer or card user desired
two different applications to interact or exchange data with each other, such as a purse
application interacting with a frequent flyer loyalty application, the card user would be
forced to swap multiple cards in and out of the card-receiving terminal during the
transaction, malting the transaction difficult, lengthy and inconvenient.
Therefore, it is beneficial to store multiple applications on the same IC
card. For example, a card user may have both a purse application and a credit/debit
application on the same card so that the user could select which type of payment (by
electronic cash or credit card) to use to make a purchase. Multiple applications could be
provided to an IC card if sufficient memory exists and an operating system capable of
supporting multiple applications is present on the card.
The increased flexibility and power of storing multiple applications on a
single card create new challenges to be overcome concerning the integrity and
security of the information (including application code and associated data) exchanged
between the individual card and the application provider as well as within the entire
system when communicating infoπnation between applications.
For instance, the existence of multiple applications on the same card
allows for the exchange of data between two applications, while one of the applications
is being executed. As stated above, a frequent flyer loyalty program may need to be
accessed during the execution of an electronic purse application. If data is passed
-3- - 22 - Iffl fl ϊSrøEϋPϊii between applications in an insecure manner, it may be possible for a third p-uty monitoring the transaction to determine the contents of the transfeπed data or even other
private data associated with one or both of the applications. Thus, it would be beneficial
to provide an application architecture and memory organization which protects .an
application's data from being discovered by a third p-irty when it is exchanged with other
applications present on the IC card.
Accordingly, it is an object of the invention to provide an application
architecture and memory organisation which provides for a secure data interaction
between applications and allows multiple applications to be accessed while
performing a desired task or function.
SUMMARY OF THE INVENTION
The present invention provides for a multiple application architecture for
an IC card called an application abstract machine (A M) .and a method for implementing
that architecture. The processing of multiple applications is accomplished by generating
for at least one application (the "first application") a data memory space including at least
two segments, a volatile memoiy segment and a non- volatile memory segment, commencing the execution of the first application's instructions; delegating or switching
execution from the first application to the delegated application and in so doing, saving
any data generated by the first application in the logical data memory space associated
with the first application; executing the second application's instructions; retrieving the - 23 - S A itiliCill saved data and completing with this data the execution of the first application's
instructions.
Additional delegation commands can be issued by the second application
or other subsequent applications. The command delegated is interpreted by a delegated application in the same manner as a selection command being issued directly by a terminal and therefore each application performs the security functions at the same level
as if a teiminal is issuing the command.
The volatile memory segment can further be separated into public
("Public") and dynamic ("Dynamic") portions. Data can be exchanged between a
plurality of applications and/or a terminal when stored in the Public region of the data
memory. The Dynamic memory region can be used solely as temporary work space for
the specific application being executed.
BRIEF DESCRIPTION OF THE DRAWINGS
Further objects, features and advantages of the invention will become
apparent from the following detailed description taken in conjunction with the
accompanying figures showing illustrative embodiments of the invention, in which
Fig. 1 is block diagram illustrating the data memory space segment and
associated registers for .an IC card application using the AAM orgaiύzation; 24 -
Fig. 2 is a block diagram illustrating the code memory and the data
memory spaces for an IC card application using the AAM architecture;
Fig. 3 is a flow diagram illustrating the steps of performing a request for a
delegation function by one application to another;
Fig. 4 is a flow diagram illustrating the steps of perfoπning a return
delegation control function for a delegate application to a delegator application;
Fig. 5 is a flow diagram illustrating the steps of performing an inquire
delegator ID request of a delegation function;
Fig. 6 is a block diagram of an IC card chip which can be used as a
platform in accordance with the invention; and
Figures 7A, 7B and 7C illustrate multiple delegation calls made between
three applications.
Throughout the figures, the same reference numerals and characters,
unless otherwise stated, are used to denote like features, elements, components or
portions of the illustrated embodiments. Moreover, while the subject invention will now
be described in detail with reference to the figures, it is done so in connection with the
illustrative embodiments. It is intended that changes and modifications can be made to
the described embodiments without departing from the true scope .and spirit of the subject
invention as defined by the appended claims. - 25 - A IU I ύv' ύ\i?ϊijiύ
DETAILED DESCRIPTION OF THE INVENTION
The present invention provides for a method and apparatus for processing multiple application programs with associated data stored on an IC card which can be accessed and executed. .An application stored on the card can be selected by a terming, or other interface device, or another application. Each application
program which is stored on the IC card when executed is allocated a memory space
organized by the program's software code (instructions which are executed by a
processor located on the IC card) and the associated data which the application stores and uses during execution of the program.
For example, a multi-application card may store a purse application, or an
electronic money application, and a specific loyalty application such as a frequent flyer
awards application. Each application has software code and associated data to support the execution of that software code. Each application is allocated a memory space when
executed. In this example, there is interaction between the two applications stored on the
card. For each dollar electronically spent to make a purchase, the user may be entitled to
one frequent flyer mile which is stored and processed by the frequent flyer progr.am. The
purse application need not be aware of the specific loyalty program stored on the card, but instead may contain an instruction to communicate with any loyalty progr.am stored
on the card. The loyalty program will require input data representative of the amount of
a particular electronic value so that it can update its own stored data of current frequent
flyer miles for the user of the card. - 26 -
When two applications need to comm municatea durimng them same transaction,
a system architecture is required to process both applications in an efficient and secure . anner. One approach could be a windows type model where both apphcations could be ^g a, the same time. Presently, however, IC card platforms are no. powerful enough
to simultaneous operate multiple programs efficient*. Also, transferred data may be
exposed to unwanted third parry access. The solution to mis problem, provided by
te current invention, which is described in greater detail below, is to selective
interrupt the execution of applications in a secure manner. This allows the integrity of the applications' data to be maintained and allows the best utilization of
0 the available memory space in the IC card.
An efficient architecture for processing multi applications in an IC card is
termed an Application Abstract Machine (AAM) architecture and is described herein. The AAM Architecture applies to any platform independent of its hardware and enables
developers to write applications to store on the IC cards which are portable across many „ different types of platfotms (e.g., IC cards built by different manufacturers with different processor configurations) without the need for knowledge about the specific hardware of
the platform.
An application absfrac. machine (AAM), a term for the memory allocation
and organization for the data stored and used by each application, is created for each
20 application stored on the IC card which is executed by the processor on the card. In order
to ensure data integrity and security when data is transferred between applications which -- A 27' -- -i"» .i»lϋϊ π AA i ivn i iitøjg yigtfrø{tTϊHwUuiai are executed on the IC card, only one application on the IC cardrø is alllowi i edl Lui be xecuted
at a time. Each application has a data memory space which is virtually allocated and
mapped onto the physical memory addresses available in the IC card memories. Data is
then passed between two or more applications within a specified memory location and in
a manner consistent with transferring data to an external terminal or device with which
the IC card is securely interacting. At a general level, each AAM space created for each
application being executed includes two separate address spaces, one for the program
code itself and one for the program data which is stored and/or used by the application.
The program data address space is effectively divided into three segments: a Static
segment, a Dynamic segment and a Public segment which are described in more detail in
conjunction with Figure 1. As stated above, the Static, Dynamic and Public segments are
logically mapped to the physical memory; they are virtual memory segments as opposed
to physical memory segments. The AAM data address space is preferably addressed and
processed using seven different address registers and two control registers.
Figure 1 shows an illustrative diagram of a logical data space allocation
101 created for an application used in conjunction with the present invention. The AJ M
data portion 101 includes a Static data space 103, a Public data space 105 and a Dynamic
data space 107. Also shown are a series of address registers: the Static base address
register 109, the Static top address register 111, the Public base address register 113, the
Public top address register 115, the Dynamic base address register 117, the Dynamic top
address register 121 and local base address register 119 which serves as a local stack O 99/38131
- 28 - ϋ ARΪΪΪΛ Π i^lltitøalFllwl frame pointer in the Dynamic data space when the application is being executed. The
address registers can contain physical memory addresses but preferably contain offset
addresses for the various data address spaces in order to be hardware independent. An
example of the overall address space is 64K bytes, although the size varies with the applicable platform and the available memory size. The registers can also be considered
pointers or can be any other conventional addressing mechanism.
Within the allocated AAM data space 101, the Static portion of the
memory is non-volatile which is not erased after power is removed from the IC card (such as EEPROM), the Dynamic space is volatile (such as RAM) which may be erased
after power is removed from the card and the Public space is also volatile (such as RAM). An IC card can receive power from a terminal after it is interfaced into the terminal.
Although an IC card may contain a battery to maintain some power for memory and
circuitry, volatile memory will typically be erased after the IC card is removed from its
power source.
The defined AAM data space has bytes in each segment which are
contiguous, so mat applications can perform pointer and offset arithmetic. For example,
if the segment addresses "1515" and "1516," or any other pair of sequential numbers, are
both valid and are present within the same segment, then they address adjacent bytes. This allows offset values stored in registers to determine the location of a desired memory
address. The segment address of the fust byte of the Static segment is zero, so that die
segment address of a given location within the Static region is equal to its offset. - 29 r-ι-..ir: P f 1
Pointers to other specific regions of the Static data area can be stored in
the Static data because the Static region is non- volatile. For example, if the card user's
name is stored in the Static memory of a credit/debit application, the application will
know the card user's name will always be stored in the 5 memory location above the
starting point for the Static portion of memory. The location can be noted as SB[5] or the
5th byte above the Static Bottom. Since the Static memory is non-volatile, it will not be
erased after each transaction and the application will always know of its location relative
to the Static segments' address registers.
On the other hand, the segment address of any location in the Dynamic or
Public segments is not always equal to a particular offset from the beginning of the
respective segment because the contents of those segments change for each operation.
The fourth location in the Dynamic segment will be different for each operation
performed by the application. The address of a memory location of Dynamic or Public
segment is fixed preferably only for the duration of one command-response pair
operation. Because segment addresses in Dynamic or Public are not fixed, MULTOS
Executable Language (MEL)™ instructions (or any other program instructions) cannot
refer to data using only segment addresses. Instead, a tagged address preferably is used to
identify data which is to be retrieved, manipulated, transferred and/or stored with the IC
card system.
A tagged address is a nineteen bit value consisting of a three bit tag
(address register number) and a sixteen bit offset. Each of the seven address registers for - 3o - 'S. * nny - '^y- ^um ' -' '} the AAM data space contain a segment physical address. For" Tnstaπcer
registers SB 109 and ST 111 point to the boundaries of the Static, the address registers
PB 113 and PT 115 point to the boundaries of the Public and the address registers DB
117 and DT 121 point to the boundaries of the Dynamic. For each segment, the top
register points to the byte immediately after the last valid byte. For example, the last
valid byte of the Static is ST[-1]. Register LB functions as a stack frame pointer. It
points to a location in the Dynamic segment to indicate a specific byte of local data for
the currently executing application.
Referring to Figure 1, the allocated Static segment 103 contains the
application's non- volatile data. Static data includes data which is associated with each
application for every transaction such as the card user's name, account number, PIN value
and address. Static data also includes variable data which is stored for use in future
transactions using the application. For example, in a purse transaction, the electronic
value data would be read from the Static segment and later saved in the Static segment at
the end of the transaction. Additionally, transaction information data or available credit
limits in the case of a credit/debit application would be stored in Static data.
The Static data is addressed using register SB (Static Base) and the
register ST (Static Top) as offset registers. These registers contain the offset value from a
physical address in a memory on the IC card. The individual memory location is then
further offset from these starting points such as SB[3] or ST[-5]. SB is defined as zero
and ST is equal to the size of the application's Static data which is set when the I JjifP
- 31 - application is loaded onto the IC card. The multiple applicatAion operating systMem ensures
that no other application can read or write the data stored in the Static segment of a
particular application. Using current technology, the Static segment is preferably mapped
onto an EEPROM (Electrically Erasable Programmable Read-Only Memory) which is
non-volatile.
The Dynamic segment 107 contains the application's volatile or temporary
data. Dynamic data includes data which is temporarily used during the execution of an
application such as intermediate values used in calculations or working variables. For
example, a purse application may temporarily store the value of a transaction in order to
reduce the amount of the value in the purse. The temporary data is used much like
conventional computer programs use RAM to perform their assigned operations. The
Dynamic segment preferably is divided into two parts, the session data portion and the
stack data portion. The size of the session data is a constant for each application and is
determined when the application is loaded. The stack holds variable data which is unique
to the particular transaction being executed. The stack data portion stores data in a last-
in-first-out manner. The stack is initially empty, but expands and contracts during
execution of the application.
The Dynamic data is addressed from the register DB 117 to register DT
121. Register LB 119 serves as a local stack frame pointer to particular memory
locations in the Dynamic segment for delegate commands or function calls. Register LB
119 is used to address the topmost frame, that of the currently executing function's S MJ!'!7 ■ "i f, ". !
- 32 - ' ' jj "' I Attica t I f L 2S 3 V:....i-i.i:l. « f, !t«! >: session data. Register DT 121 serves as an address offset for the stack pointer. A one
byte data item at the top of the stack is addressed as DT[-1], the next byte below is
addressed by DT[-2], and so on. A push operation increments the relative value of DT
for each item on the stack and a pop operation decrements the relative value of DT for
each item on the stack. For example, a data element located at DT[-5] will be located at
DT[-6] after an additional data item is placed on the stack.
When an application is being executed, the Dynamic segment created for
that application also contains the application's session data which is used in performing
the assigned task(s) or operation(s). The multiple application operating system ensures
that no other application can read or write the data stored in the Dynamic segment of a
particular application. The session data is set to zero upon the start of the execution of
the application. Stack data will be saved in the stack if the application delegates a task or
operation to another application.
A delegation function occurs when one application selects another
application to process a command instead of processing the command itself. .An example
of a delegation function occurs when a delegator application receives a command that it
does not recognize or is not programmed to process. The selected application should not
reject the command and provide an error response to the interface device (IFD), but
instead should pass the command to the appropriate receiver, or delegated application. In
order to perform a delegation, the delegator calls the Delegate primitive. The Delegate
primitive is a subroutine recognized by the multiple application operating system which - 33 - fl ϊ( is executed when the operating system interprets the Delegate instruction. Primitives can
be stored as part of the operating system itself, loaded as a separate routine when the
operating system is installed. Primitives are preferably written in machine executable
language so that they can be executed quickly although they could be written in a higher
level language. When a Delegate command is executed, execution of the delegating
application is suspended, and the delegated application is executed instead. The
delegated application then generates its own data memory space according to the AAM
architecture. The data stored in the Public memory space of the first application (stored
in RAM) is sent to the Public memory space of the second application (which could be
physically the same memory but is allocated separately for each application) so that data
can be passed between the applications. The Dynamic memory space is also shared
although data is saved in a stack for the delegator and the other portions initialized before
the delegated application is executed because the Dynamic data is secret.
In most cases, the delegated application processes the command exactly
as though the command has arrived directly from an interface device. When the
delegated application has finished processing the command, and has written a response
into the allocated Public memory segment, it exits as normal. The delegator then resumes
execution at the instruction address following the executed instruction which called the
Delegate primitive. The response generated by the delegated application is retrieved or
accessed from the allocated Public memory space. The delegator application may simply - 34 - _ Y exit in turn, thus sending the response to the IFD, or may cany out further processing
before exiting.
./Another example of a delegation operation occurs when two applications
need to share data. If an application A always returns a data item N when processing a
command B, then another application which also returns data item N in response to a
command can delegate the function B to application A in order to reduce the need for
duplicate codes stored on the IC card. For example, if a PIN needs to be checked before
an application is executed, an application stored on the card can delegate the "retrieve
PIN function" to a PIN application which returns a stored universal PIN for the card.
Preferably, a new session begins whenever the IFD, e.g. a terminal,
successfully selects an application, even if the application has been previously selected
during the transaction. For example, if a card user goes to a terminal and transfers twenty
dollars of electronic cash using a purse application, charges thirty dollars using a
credit/debit application and then transfers ten dollars using the purse application again,
three separate sessions will have occurred even though only two applications were used
during the entire transaction. Each time an application delegates a task or function to
another application, the delegated application treats the delegate function as if the IFD
devices had selected the application to perform the task or function. However,
performing a delegation function as described below has a different effect on session
data. 35 - iϋ A TO THE DES IPTIO
The following examples will help explain when the session data is
initialized (i.e., erased) versus when it is saved to be used in further operations. If
application A is selected by an IFD device, and receives commands X, Y and Z from the
terminal, application A may delegate all three commands to application B. For example,
delegations may occur in response to delegation comma. nds in the program code. Both
applications A and B will have their session and stack data in their respective Dynamic
segments initialized (set to zero) when they receive command X, but the stack will not be
initialized when they receive the subsequent commands Y and Z.
In a second example, application A is selected, and receives commands X,
Y and Z from the terminal. Application A processes X itself, but delegates Y and Z to
application B. Application A will have its session and stack data initialized when it
receives X, but not when it receives the subsequent commands Y and Z. Application B
will have its session and stack data initialized when it receives Y, but not Z.
One example of a use of session data is to support the use of a session
Personal Identification Number (PIN). The application could reserve one byte of session
data to support the PIN-receiving flag. On receiving the PIN check command, the
selected delegated application could update the flag as follows: if the PIN command is
received and the inputted PIN is equal to the stored pin, then it will set the session data
DB[0] to 1. If not, the application will check if the PIN flag is already set by checking
the value in DB[0]. In either of the above cases, the application will process the rest of
the commands in the session because the PIN has been verified. If neither of the cases is - 36 - /=> .ϋ ilGαn true, then the application will not process the command because the PIN is not proper.
The PIN checking function could be a delegated function from the selected application to a PIN checking application.
The Public segment 105 is used for command and response data being
passed between an IFD and an application. During a delegate command, the Public
segment contains the data passed between two applications, the delegator (the application
initiating the delegation) and the delegated application (the application which performs
the delegated function). An application may also use the Public segment as a further
temporary working storage space if required. The Public data is addressed using offsets
stored in register PB 113 as a starting address, to register PT 115 as an ending address.
Register PB 113 and Register PT 115 are fixed for the duration of a command-response
pair being initiated by the IFD or delegator. Public data can include data inputted into or
supplied by a terminal such as a transaction amount, vendor identification data, terminal
information, transmission format or other data required or used by an application resident on the IC card. Public data can also include data which is to be transmitted to an IFD
device or other application such as an electronic dollar value, card user information
transmission format or other data required or used by the terminal or other delegated application.
The multiple application operating system ensures that the data stored in
the Public segment remains private to the application until the application exits or
delegates. Preferably, the data in the Public segment is then made available to other - 37 - entities as follows: (1) if the application delegates, th lee wwhhoollee ooff t thhee PPuubblliicc sseeggmmeenntt
becomes available to the delegated application; (2) if the application exits, and is itself
delegated by another, the whole of the Public segment becomes available to the delegator;
or (3) if the application exits, and is not itself delegated, then a portion of the Public
segment containing the I/O response parameters and data are made available to the IFD.
. n application may write secret data into the Public memory segment
during execution of the application, but the application must make sure it overwrites the
secret portion of the Public segment before delegating or exiting. If the application
abnormally ends (abends), then the operating system on the IC card preferably overwrites
all of the data in the Public segment automatically so that no unwanted entities can have
access to the secret data. If the MULTOS carrier device (MCD) is reset, the operating
system overwrites data in the Public segment automatically, so that no secret data is
revealed. A portion of the Public memory segment is also used as a communications
buffer. The I/O protocol data and parameters are preferably stored at the top of the Public
memory space. In another prefeιτed embodiment, the top seventeen bytes are reserved
for the communications protocol between the IFD device and the IC card application.
However, additional or less bytes can also be used depending upon the particular
application and operating system being utilized.
The spaces shown between the memoiy segments in Figure 1 will vary
depending upon the specific application and commands being processed. There could be - 38 - SI A TO THE DESffilPTfON no memory space between the memory segments so that the memory segments are
contiguous.
Figure 2 shows an extended illustration of the AAM implemented
architecture. Data memory space 201 includes the three segments Static, Public and
Dynamic as previously described. Code memory space 203 contains the program
instructions for an application stored on the IC card. The application instructions are
preferably stored in an executable form which can be inteφreted by the resident operating
system but can also be stored in machine executable form. Instruction 205 is stored at
one location in the code memory space 203. Additional instructions are stored in other
locations of memory space 203. Two additional registers 207 and 209 are used in the
AAM architecture. A code pointer (CP) register 207 indicates the particular code
instruction to be next executed. In the figure, the register indicates, e.g., through an offset
or pointer means, that instruction 205 is the next to be executed. Condition Control
Register 209 contains eight bits, four of which are for use by the individual application
and four of which are set or cleared depending upon the results of the execution of an
instruction. These condition codes can be used by conditional instructions such as
Branch, Call or Jump. The condition codes can include a carry bit, an overflow bit, a
negative bit and a zero bit.
All address and control registers are set to defined values prior to
executing the selected or delegated application. The values are set either when the
application is first loaded onto the card and the size of the code and non- volatile data can O 99/38131
- 39 - m f\ roiiroπoK be ascertained or at the moment when the application passes control to the application.
When the application is loaded, SB is set to zero and ST is equal to the number of bytes in the application's Static database. The other address registers are initialized when the
application is given control. CP 207 is set to zero and all eight bits in CCR 209 are
cleared at the start of executing the application.
A communications interface mechanism is present between the IFD and an
application which includes the use of the Public data segment as a communications buffer
for command-response parameters. A command-response parameter means an application is given a command to perform and returns a response to the entity issuing the
command. Applications interact with an IFD by receiving commands, processing them
and returning responses across the IFD-Application Interface. When an application has completed executing a command, the application will place the response into the Public
segment starting at PB[0] which can be read by the IFD device and will set the proper
interface parameters in the reserved Public space relative to PT[0].
While an application can be called directly from an IFD and return a
response directly to an IFD, it can also delegate a request to another application where appropriate. The subsequently-called application will then process the request on behalf
of the first application. The delegation can be directly in response to a received command
in which the delegator acts as a controller for delegating commands or subcommands to
other appropriate applications. Alternatively, the delegated command can be embedded
in an application's code which delegates control of the processor when the first - 40 - IX A application needs to interact with another application during its execution, such as
updating frequent flyer miles or verifying a PIN.
Figure 3 shows a flow chart of the steps which are performed when a
delegate request is executed. Step 301 sets the parameter named delegator_application_id
(delegator ID) to be equal to the selected_file.application_id (selected ID). The selected
ID indicates the current application which is selected and which is currently being
executed. The delegator ID indicates the application which delegates a function to
another delegated application stored on the IC card. Step 303 then pushes (stores) the
delegator ID onto the top of the delegate_id_stack (delegate stack). The data referenced
in the Dynamic portion of allocated memory is saved so that the current application can
complete its execution after the delegated function is complete. Data which is to be
shared with the delegated application is referenced in the Public portion of allocated
memory. The delegate stack is preferably stored outside of an application's AAM
memory space and keeps track of which applications have delegated functions. Each
application is suspended when it delegates a function so the delegate stack can act in a
Last-In-First-Out (LIFO) manner so that if a number of applications are suspended due to
delegation requests, the proper application is started in the right order. The delegate stack
thus keeps track of which application was the last delegator when multiple layered
delegation functions are performed. The delegate stack preferably operates in a LIFO
o manner although different stack schemes could be used as appropriate. O 99/38131
- 41 - a β Toiro iPTi
Step 305 then sets the selected ID to the delegate_request.delegate_
applicationjd (delegate ID) value. This step selects the application which will be called
to perform the delegated function or functions. The identities of the delegated application
can be specifically called by the delegator application or a particular function can be
matched up with an application in a look up table. For example, a PIN match operation
may be delegated to different applications depending upon which applications are present
on the card. Step 307 then sets the application_command parameter to the value stored in
the delegate_request.application_command parameter. This step specifies the command
to be delegated to the delegate application. Applications typically have the ability to
process many different commands. Alternatively, the entire application could be
executed to perform one or more functions. The delegator application can choose which
command it is delegating to another application. Step 309 then sends the application_command to the AAM operating system for execution by the delegatee
application. The delegator application is then suspended (or interrupted). .Any data that
is required to pass between the applications is transferred via the Public memory space.
Figure 4 is a flow chart of the steps for performing a "return delegation
control" command by the delegatee application. This command is executed by the
operating system when a delegated application has completed its delegated function.
Step 401 gets application_responses from the Public memory space of the delegated
AAM. The response data is passed in the Public memory segment of the delegatee AAM.
Step 403 then sets the delegate_response. status variable to a success condition. This - 42 ANNEX ^l TO THE DESCRIPTION means that a delegation operation has been successfully completed. Step 405 sets the delegate, response.application_responses parameter to the application_responses values
which were stored in the Public segment of the delegatee application.
Step 407 sets the delegate_response.delegate_application_id parameter to
Selected_file.application_id (the delegatee application ID). Step 409 pops the top (i.e.,
reads the last data stored in the stack) delegate_application_id from the delegate_id_stack. This information indicates the identity of the delegator application for
the command which was just delegated and completed by the delegated application. Step 411 sets the select_file.application_id value to the delegator_application_id value. This
o selects the delegator application which was identified from the delegate ID stack as the
current application which will resume running. The Dynamic data for the delegator application will be retrieved for the delegator application from its stored location so that the application will continue to execute where it left off with all data intact but will also
have the response information from the delegated function. In step 413, the .5 delegate_response data is sent to the current application for further processing. The
response data is passed through the Public data space which could be the same physical RAM memory location because all applications share the physical volatile memory space.
Figure 5 shows a flow chart of the steps involved for inquiring about a
delegator ID when a delegate command is received by a delegated application. The
2 o delegated application may need to know the identity of the delegator because it may
perform operations differently for different delegator applications. For example, an - 43 - fi i r.7 airline loyalty program may need to l now if awarded frequent flyers will be based on
actual dollars processed or a lump sum award for some other activity such as performing
a bill payment operation. This information could be passed to the delegated application
as a variable or could be ascertained using an inquiry. The delegator inquiry operation
could be implemented as a primitive as previously described.
Step 501 receives the delegator_id_enq_request from the AAM operating
system. The request is used to identify the identity of the delegator. Step 503 checks if
the delegate_id_stack is empty. If the stack is empty, then no delegation operations have
occurred and no applications have been suspended. Thus step 511 sets the
delegator_id_enq_response. status parameter to a failure indicator. Step 513 then sets the
value of delegator_is_enq_request.error_cause to a value indicating "no delegator
application." There is no delegator application. The process then continues with step
509.
If the delegate_id_stack is not empty, than one or more delegations have
occurred. In that case, step 505 sets the delegator_id_enq_response.status parameter to a
value indicating "success". Step 507 then sets the delegator_id_enq_response.delegator_
application_id parameter to the value stored in delegate_id_stack.delegator_
application_id. This sets the inquiry response to indicate the delegator application ID at
the top of the stack. As explained above, the stored data at the top of the stack indicates
the last delegator application to call a delegate function. Step 509 then sends the I f. L'.-'ϊi.' m
1 » fl iU ink WU Ail iivM
- 44 - delegator_id_enq_ response back to the AAM operator system wliich delivers the
information to the application or IFD entity requesting the information.
Figure 6 shows an example of a block diagram of an integrated circuit
located on an IC card chip which can be used in conjunction with the invention. The
integrated circuit chip is located on a chip on the card. The IC chip preferably includes a
central processing unit 601, a RAM 603, a EEPROM 605, a ROM 607, a timer 609,
control logic 611, I/O ports 613 and security circuitry 615, which are connected together
by a conventional data bus 617 or other conventional means.
Control logic 611 in the smart card provides sufficient sequencing and
switching to handle read- write access to the card's memory through the input output ports
612. CPU 601 in conjunction with control logic 611 can perform many different
functions including performing calculations, accessing memory locations, modifying
memory contents, and managing input output ports. Some IC cards also include a
coprocessor for handling complex computations like cryptographic algorithms.
s Input/output ports 613 are used for communication between the card and an IFD which
transfers infoπnation to and from the card. Timer 609 (which generates and/or provides a
clock pulse) drives the control logic 611, CPU 601 and other components requiring a
clock signal through the sequence of steps that accomplish functions including memory
access, memoiy reading and/or writing, processing, and data communication. Security
o circuitry 615 (wliich is optional) preferably includes fusible links that connect the
input/output lines to internal circuitry as required for testing during manufacture, but - 45 - il ATOlDM i which are destroyed upon completion of testing to prevent later access. The Static
memory space is preferably mapped to memory locations in EEPROM 605 which is non¬ volatile. The Dynamic memory space is preferably mapped to RAM 603 which is
volatile memory which has quick access. The Public memory space is also preferably
mapped to RAM 603 which is volatile memory. The Dynamic data and Public data will
be stored in different portions of RAM 603, while RAM is identified as a preferred non¬
volatile memory and EEPROM is identified as a preferred volatile memory. Other types of memory could also be used with the same characteristics.
Figures 7A, 7B and 7C illustrate an example of a delegation function being performed in order to process multiple applications on an IC card. Figure 7A
shows a first application being executed as denoted with a double ringed circle 701. At
some point during the execution of the first application, a delegation function 702 is
called to delegate an operation to the second application which is indicated by circle 703.
Also shown in Figure 7A is an empty delegator ID stack 705. Since the stack is empty, there is no data associated with it and it is shown only for illustrative purposes.
The multiple application operating system receives the delegate command
and interrupts the execution of the first application 701 and gives control of the integrated
circuit to application 703 as shown in Figure 7B. The execution of the second application
703 is illustrated with a double ringed circle. The term "gives control" means that the
microprocessor and other circuitry on the card will process the instructions and allocate
memory space for the application which is delegated. When the delegate command is - 46 - JJ fl TOlUti lrπui, t processed, the delegator ID 707 is placed on top of the stack 705. The delegator ID stack
is operated in a LIFO manner. Also shown in Figure 7B is a third application 709
resident on the card. At some point during the execution of the second application, a
delegate function 711 is called to delegate the operation to the third application.
The multiple application operating system receives the delegate command
711 shown in Figure 7B interrupts the execution of the second application 703 and gives
control of the integrated circuit to the third application 709 as shown in Figure 7C. When
the delegate command is processed, the delegator ID 713 of the second application is
pushed onto the delegator ID stack 705. The delegator ID 707 of the first application
whose execution is still interrupted is pushed down in the stack consistent with a LIFO
stack management. Thus when the third application has finished its execution, the
delegator ID at the top of the stack is popped to indicate that execution of the second
application should be resumed first. The delegator ID 707 from the first application will
then be at the top of the stack so that when the second application is finished executing,
the first application will resume its execution.
Additional applications can be managed by the delegator ID stack in a
similar manner. By interrupting the execution of the applications when a delegate
command is processed and keeping track of the order of delegations, the security and
integrity of the data for each individual application can be maintained which is important
because IC cards will store data for applications which is private to the card user such as
account numbers, social security number, address and other personal infoπnation. 47 - m AiiCM
The foregoing merely illustrates the principles of the invention. It will
thus be appreciated that those skilled in the art will be able to devise numerous apparatus,
systems and methods which, although not explicitly shown or described herein, embody
the principles of the invention and are thus within the spirit and scope of the invention.
- 48 - WE CLAIM: H1X 9 TOTHEDESCRlPiiON
1. -An integrated circuit card comprising: a microprocessor; a volatile memory coupled to said
microprocessor; a non-volatile memory coupled to said microprocessor; and a plurality of
applications stored in said non-volatile memory, wherein upon execution of each said
application, said microprocessor allocates for each said executing application an
associated data memory space comprising at least a volatile memory segment for
referencing temporary data and a non- volatile memory segment for referencing static
data; and further comprising means for delegating the performance of a function from a
first executing application to a second executing application.
2. The integrated circuit card of claim 1 , wherein said non- volatile memory segment
is divided into at least two regions, including a public region and a dynamic region.
3. The integrated circuit card of claim 2, wherein said public region is used to share
data between said first and second applications.
4. The integrated circuit card of claim 2, wherein said dynamic region is
used to reference temporary data utilized during an application's execution. - 49 - ANNEX f. mmwi i 5. The integrated circuit card of claim 1, further comprising at least one
2 register coupled to said microprocessor which is used to determine the starting locations
3 of each of said segments.
i 6. The integrated circuit card of claim 5, further comprising at least one
2 register coupled to said microprocessor which is used to determine the top locations of
3 each of said segments.
ι 7. The integrated circuit card of claim 6, further comprising at least one
2 register coupled to said microprocessor which is used as a local dynamic pointer.
1 8. The integrated circuit card of claim 1, wherein each said
2 application comprise a plurality of program instructions and wherein at least one of said
3 program instructions when executed causes said memory referenced by said volatile
4 memory segment to be accessed.
i 9. The integrated circuit card of claim 1, wherein said volatile memory
2 segment references RAM and said non-volatile memoiy segment references EEPROM.
1 10. A method for processing a plurality of applications stored in a memory of an
2 integrated circuit: 50 iii ft TOIOT I selecting a first application for execution; allocating a data space for said first application including at least
two memory segments comprising a volatile memory segment for referencing temporary
data and a non- volatile memory segment for referencing static data; executing said first application, interrupting execution of said first
application and saving data referenced by said volatile memory segment; executing a second application; utilizing said saved data from said volatile memory segment for
execution of said first application; and 0 completing said execution of said first application.
i 11. The method of claim 10, wherein said first application' s identity is stored in a data
2 stack during said delegation step.
i 12. The method of claim 11 , wherein said data stack is accessed following said
2 completion of said second application.
i 13. The method of claim 12, further including the step of inquiring said first
2 application' s identity by accessing said delegator stack.
ι 14. The method of claim 10, wherein said non-volatile memory segment
2 is divided into at least two regions, including a public region and a dynamic region. - 51 - m ft TO THE DESCRIPTION
1 15. The method of claim 14, wherein said public region is used to share data between
2 said first application and said second application.
i 16. The method of claim 14, wherein data referenced by said dynamic region is
2 utilized during the execution of said first application.
1 17. The method of claim 10, further including the step of allocating a
2 second data space including at least two memory segments for said second application.
*
1 18. The method of claim 17, wherein said second data space's segments comprise a
2 volatile memory segment for referencing temporary data and a non- volatile memory
3 segment for referencing static data.
1 19. The method of claim 18, wherein said second application's non- volatile segment
2 is divided into at least two regions, including a public region and a dynamic region.
1 20. The method of claim 19, wherein said second application's public region is used
2 to share data between said first and second applications.
i 21. The method of claim 19, wherein said data referenced by second
2 application's dynamic region is utilized during said execution of said second application. - 52 - ft TO I M il 2. The method of claim 10, further including the step of delegating use
of said microprocessor from said second application to a third application stored on said
IC card.
23. The method of claim 22, wherein a third data space for said third application is
allocated which includes a volatile memory segment for referencing temporary data and
non- volatile memory segment for referencing static data, wherein said third application's
volatile segment includes a public and dynamic portion.
24. .An apparatus for processing a plurality of applications stored in a memory of a
single integrated circuit card comprising: means for allocating a data space comprising at least a non-volatile
memory segment for referencing static data and a volatile memory segment for
referencing temporary data; means for executing a first application; means for
interrupting execution of said first application, means for saving data from at least a
portion of said volatile memory segment; and means for executing a second application;
means for retrieving said saved data; and means for completing said execution of said
first application.
25. The apparatus of claim 24, further including means for storing said first
application's identity on a data stack. - 53 ft TϋKSβtøT 26. The apparatus of claim 25, further including means for inquiring of said first
application's identity.
27. The apparatus of claim 24, wherein said first application's non-
volatile memory segment is divided into at least two regions, including a public region
and a dynamic region.
28. The apparatus of claim 27, wherein said public region references random access
memory.
29. The apparatus of claim 27, wherein said dynamic region references random
access memory.
30. The apparatus of claim 24, further including means for allocating a
second data space including at least two segments for said second application.
31. The apparatus of claim 30, wherein said second data space includes a volatile
memory segment for referencing temporary data and a non-volatile memory segment for
referencing static data. - 54 - u oMH i
1 32. The apparatus of claim 31 , wherein said second data space's non-volatile segment
2 is divided into at least two regions, including a public region and a dynamic region.
ι 33. The apparatus of claim 32, wherein said public region references random access 2 memory.
1 34. The apparatus of claim 32, wherein said dynamic region references random
2 access memory.
1 35. The apparatus of claim 24, further including means for delegating
2 operation of said IC card from said second application to a third application stored on
3 said IC card.
ι 36. The apparatus of claim 35, wherein a third data space for said third application is
2 allocated which includes a volatile memory segment for referencing temporary data and
3 non-volatile memory segment for referencing temporary data, wherein said third
4 application's volatile memory segment includes a public and dynamic portion.
ι 37. A system for processing a plurality of applications stored on an IC card
2 comprising:
a non-volatile memory coupled to a databus; O 99/38131
m Ft Toitn yi ft a volatile memory coupled to said databus; a first and second application program stored in said non-volatile memory,
wherein each application has an associated identifier; a data stack accessible by said databus for storing said applications'
identifier if said application is interrupted during its execution; processor means for executing instructions from said application programs
wherein said processor means allocates a data memory space for said application which is
being executed and said data memory space is mapped to at least one address in said non-
volatile memory and at least one address in said volatile memory; and wherein said processor means interrupts said first application at least once
during its execution to execute said second application.
38. The system of claim 37, wherein data memory space comprises at least a volatile
memory segment for referencing temporary data stored in said volatile memory and a
non-volatile memory segment for referencing static data stored in said non-volatile
memory.
39. The system of claim 37, further including means for storing said first
application's identity on a data stack.
40. The system of claim 39, further including means for inquiring of
said first application's identity. - 56 - JIU ft TO u i ι 41. The system of claim 38, wherein said first application's non-volatile
2 memory segment is divided into at least two regions, including a public region and a
3 dynamic region.
1 42. The system of claim 41, wherein said public region references random access
2 memory.
i 43. The system of claim 41, wherein said dynamic region references random
2 access memory.
i 44. The system of claim 37, further including means for allocating a
2 second data space including at least two segments for said second application.
1 45. The system of claim 44, wherein said second data space comprises at least a
2 volatile memory segment for referencing temporary data and a non- volatile memory
3 segment for referencing static data.
1 46. The system of claim 45, wherein said second data space's non-volatile segment is
2 divided into at least two regions, including a public region and a dynamic region. - 57 - P uπ-i ι 47. The system of claim 46, wherein said public region references random access 2 memory.
1 48. The system of claim 46, wherein said dynamic region references random access
2 memory.
ι 49. The system of claim 37, further including means for delegating use
2 of said processor means from said second application to a third application stored on said
3 IC card.
50. The system of claim 49, wherein a third data space for said third application is
allocated which includes a volatile memory segment for referencing temporary data and
non-volatile memory segment for referencing temporary data, wherein said third
application's volatile memory segment includes a public and dynamic portion.
51. An integrated circuit card comprising:
a plurality of applications and a microprocessor for controlling execution of said applications wherein execution of at least one first application is
interrupted and execution is transferred to another second application, further comprising
means for sharing data by said first and second applications and means for resuming
execution of said first application at the appropriate location at least after completion of execution of said second application. - 58 - HA TOIin i 52. The integrated circuit card of claim 51 , further comprising means for allocating a
data memory space comprises at least a volatile memory segment for referencing
3 temporary data stored in said volatile memory and a non-volatile memory segment for
4 referencing static data stored in said non-volatile memory.
ι 53. The integrated circuit card of claim 51 , further including means for storing
2 said first application's identity on a data stack.
1 54. The integrated circuit card of claim 53, further including means for
2 inquiring of said first application's identity.
1 55. The integrated circuit card of claim 52, wherein said first application's non-
2 volatile memory segment is divided into at least two regions, including a public region
3 and a dynamic region.
1 56. The integrated circuit card of claim 55, wherein said public region references
2 random access memory.
i 57. The integrated circuit card of claim 55, wherein said dynamic region
2 references random access memoiy. - 59 - mv.m πSmmm t l IT III* -n ra-rtMinl π vπ i 58. The integrated circuit card of claim 52, further including means for
2 allocating a second data space including at least two segments for said second
3 application.
i 59. The integrated circuit card of claim 58, wherein said second data space comprises
2 at least a volatile memory segment for referencing temporary data and a non-volatile
3 memory segment for referencing static data.
i 60. The integrated circuit of claim 58, wherein said second data space's non-
2 volatile segment is divided into at least two regions, including a public region and a
3 dynamic region.
61 The integrated circuit of claim 58 , wherein said public region references
2 random access memory.
ι 62. The integrated circuit card of claim 60, wherein said dynamic region
2 references random access memory.
i 63 The integrated circuit card of claim 51 , further including means for
2 delegating use of said processor means from said second application to a third application
3 stored on said IC card. - 60 -
Ø TOIJ PTION
ABSTRACT OF THE DISCLOSURE
A multi-application IC card which processes two or more applications
using an Application Abstract Machine architecture. The AAM architecture only allows
one application to be executed at a time and allows for shared processing by performing a
delegation function to a second application. A data space for each application is allocated
when the application is selected to be executed. The data space includes a volatile and
non- volatile region. The delegation function temporarily interrupts the execution of the
first application, saves the temporary data of the first application, shares any data needed
with the second application and the second application is executed until the delegated
task is competed. The first application then retrieves the saved data and completes its
execution. A delegator stack is used to keep track of the delegator' s identity when
multiple delegations occur. The AAM model allows for a high level of security while
transferring data between applications.

Claims

- 61 -CLAIMS
1. An integrated circuit card comprising:
a read-only memory;
an alterable memory;
a microprocessor coupled to said read-only and alterable memoiy;
an operating system stored in said read-only memory, wherein said
operating system is executed by said microprocessor;
at least one application stored in said alterable memory; and
a codelet stored in said read-only memory and comprising at least one
non-native program instruction.
2. The integrated circuit card of claim 1, wherein said alterable
memoiy comprises an EEPROM.
3. The integrated circuit card of claim 1 or claim 2 wherein one of said
ΓÖª application's program instruction calls said codelet.
4. The integrated circuit card of .any preceding claim, further comprising an address table for storing said memory address and identifier of said stored codelet. - 62 -
5. The integrated circuit card of claim 4, wherein said address table is
stored in sήd alterable memoiy.
6. The integrated circuit card of claim 4 or claim 5, wherein said operating system executes said codelet by lool ing up said codelet's memoiy address in said address table using said codelet's identifier.
7. The integrated circuit card of any preceding claim, further including a primitive stored in said read-only memory.
8. The integrated circuit card of claim 7, wherein said primitive
verifies said codelet's presence on said IC card.
9. The IC card of cl^m 8, further including a register indicative of
said codelet's presence.
10. The integrated circuit card of any of claims 7 to 9, wherein said codelet executes said primitive.
- 63 - 11. The integrated circuit card of claim 10, wherein s.aid execution of
said primitive uses an address table look up to determine said primitive's memory
location.
12. A method for efficiently storing programming instructions in a
microprocessor system including read-only memory and alterable memory comprising
the steps of:
storing an operating system in sad read-only memory;
storing at least one application written in a non-native computer language
in said alterable memory;
storing a codelet comprising program instructions written in a non-native
computer language in said read-only memory; and
storing said codelet's address location in an address table;
wherein said codelet is accessed by said operating system using said
address table.
13. The method of claim 12, wherein said alterable memory comprises
EEPROM. - 64 -
14. The method of claim 12 or 13, wherein one of said application's program instructions calls said codelet.
15. The method of any of claims 12 to 14, wherein said address table is stored in said alterable memory.
16. The method of any of claims 12 to 15, wherein said operating system executes said codelet by looking up said codelet's memory address in said address table.
17. The method of any of claims 12 to 16, wherein said address table is stored in said read-only memory.
18. The method of any of claims 12 to 17, further including the step of storing a primitive in said read-only memory.
19. The method of any of claims 12 to 18, wherein said non-native computer language of said at least one application is said non-native computer language of said codelet.
- 65 -
20. The method of any of claims 12 to 19, further including the step of verifying the presence of said codelet on said IC card.
21. A system for efficiently storing program instructions in a
microprocessor b.ased system comprising:
A read-only memory storing an operating .system and at least one codelet,
wherein said codelet comprises program instructions written in a non-native
programming language requiring interpretation by said operating system; and
.An alterable memory storing at least one application comprising program
instructions and data and an address table;
wherein said memory address and identifier of said codelet is stored in
said address table and said codelet is accessed by said at least one application during said
application's execution.
22. The system of claim 21 , wherein said codelet's program instruction
utilizes s.aid application's data.
23. The system of claim 21 or 22, further including a means for verifying said codelet's presence in said read-only memory. - 66 -
24. The system of any of claims 21 to 23, wherein said system resides on an integrated circuit card.
25. The system of any of claims 21 to 24, wherein said operating system executes said codelet by looking up said codelet's memory address in said address table using said codelet's identifier.
EP99901065A 1998-01-22 1999-01-21 Codelets Withdrawn EP1050028A1 (en)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US7256198P 1998-01-22 1998-01-22
US72561P 1998-01-22
PCT/GB1999/000209 WO1999038131A1 (en) 1998-01-22 1999-01-21 Codelets

Publications (1)

Publication Number Publication Date
EP1050028A1 true EP1050028A1 (en) 2000-11-08

Family

ID=22108399

Family Applications (1)

Application Number Title Priority Date Filing Date
EP99901065A Withdrawn EP1050028A1 (en) 1998-01-22 1999-01-21 Codelets

Country Status (4)

Country Link
EP (1) EP1050028A1 (en)
JP (1) JP2002501269A (en)
AU (1) AU2069199A (en)
WO (1) WO1999038131A1 (en)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FI114434B (en) * 1999-05-11 2004-10-15 Nokia Corp communication equipment
EP1210697A1 (en) 1999-09-07 2002-06-05 Swisscom Mobile AG Ordering method
DE10216602A1 (en) 2002-04-15 2003-10-30 Giesecke & Devrient Gmbh Optimization of compiler generated program code
FR2841997B1 (en) * 2002-07-08 2005-11-11 Gemplus Card Int SECURING APPLICATION DOWNLOADED IN PARTICULAR IN A CHIP CARD
CH716409B1 (en) * 2003-11-12 2021-01-29 Legic Identsystems Ag Method for writing a data organization in identification media and for writing and executing applications in the data organization.

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0218176B1 (en) * 1985-10-07 1991-11-13 Kabushiki Kaisha Toshiba Portable electronic device
JPS63268031A (en) * 1987-04-24 1988-11-04 Sharp Corp Program execution control system
JPH03291786A (en) * 1990-04-10 1991-12-20 Matsushita Electric Ind Co Ltd Ic card
EP0466969B1 (en) * 1990-07-20 1994-01-12 Siemens Nixdorf Informationssysteme Aktiengesellschaft Method for preventing unauthorised deviations from an application development protocol in a data exchange system
FR2667171B1 (en) * 1990-09-25 1994-08-26 Gemplus Card Int PORTABLE MEDIUM WITH EASILY PROGRAMMABLE MICRO-CIRCUIT AND METHOD FOR PROGRAMMING THIS MICRO-CIRCUIT.
FR2683357A1 (en) * 1991-10-30 1993-05-07 Philips Composants MICROCIRCUIT FOR PROTECTED PROGRAMMABLE MEMORY CHIP CARD.
US5682027A (en) * 1992-10-26 1997-10-28 Intellect Australia Pty Ltd. System and method for performing transactions and a portable intelligent device therefore
JP3231467B2 (en) * 1993-03-24 2001-11-19 大日本印刷株式会社 Information recording medium with built-in CPU
FR2713803B1 (en) * 1993-12-07 1996-01-12 Gemplus Card Int Memory card and operating method.
JP3594672B2 (en) * 1994-11-29 2004-12-02 大日本印刷株式会社 IC card
FR2734934B1 (en) * 1995-05-30 1997-07-04 Syseca SECURE INTELLIGENT CHIP CARD

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO9938131A1 *

Also Published As

Publication number Publication date
WO1999038131A1 (en) 1999-07-29
JP2002501269A (en) 2002-01-15
AU2069199A (en) 1999-08-09

Similar Documents

Publication Publication Date Title
US6220510B1 (en) Multi-application IC card with delegation feature
EP0981805A1 (en) Ic card with shell feature
US5754762A (en) Secure multiple application IC card using interrupt instruction issued by operating system or application program to control operation flag that determines the operational mode of bi-modal CPU
US7689826B2 (en) Flexibly loading a tamper resistant module
US6742715B2 (en) System and method for flexibly loading an IC card
RU2148856C1 (en) Information exchange system
KR100205740B1 (en) A secure application card for sharing application data and procedures among a plurality of microprocessors
US6357665B1 (en) Configuration of IC card
US5805083A (en) Electronic parking meter operating system
US6687800B1 (en) Chip card comprising means and method for managing a virtual memory and associated communication method
EP1450299B1 (en) Portable information recording medium
EP1053535B1 (en) Configuration of ic card
US7025261B2 (en) Method and system for managing data designed to be stored in a programmable smart card
US6736325B1 (en) Codelets
WO1999038131A1 (en) Codelets
JP3515417B2 (en) Methods and apparatus for creating objects in non-persistent memory and methods for maintaining accessibility to objects
JP2003076954A (en) Ic card using a plurality of operating systems, ic card processor and its method
WO1998052152A2 (en) Communication between interface device and ic card
GB2350703A (en) Smart devices
EP1384197B1 (en) Method of manufacturing smart cards
JPH11328273A (en) Utilization limit setting method, execution system therefor and medium recording processing program therefor
CA2545292C (en) A method for writing data and applications into identification media
AU8343998A (en) Security module comprising means generating links between main files and auxi liary files
EP3926504A1 (en) Hiding and unhiding java card applet instances
JPH023823A (en) Ic card

Legal Events

Date Code Title Description
PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

17P Request for examination filed

Effective date: 20000823

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AT BE CH CY DE DK ES FI FR GB GR IE IT LI LU MC NL PT SE

17Q First examination report despatched

Effective date: 20020322

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE APPLICATION HAS BEEN WITHDRAWN

18W Application withdrawn

Effective date: 20100721

REG Reference to a national code

Ref country code: HK

Ref legal event code: WD

Ref document number: 1032467

Country of ref document: HK