WO2001016707A1 - Système d'exploitation de cartes à puce doté d'interfaces - Google Patents

Système d'exploitation de cartes à puce doté d'interfaces Download PDF

Info

Publication number
WO2001016707A1
WO2001016707A1 PCT/US2000/000078 US0000078W WO0116707A1 WO 2001016707 A1 WO2001016707 A1 WO 2001016707A1 US 0000078 W US0000078 W US 0000078W WO 0116707 A1 WO0116707 A1 WO 0116707A1
Authority
WO
WIPO (PCT)
Prior art keywords
smart card
functions
application
command
microprocessor
Prior art date
Application number
PCT/US2000/000078
Other languages
English (en)
Inventor
Todd Carper
Original Assignee
Cryptec Systems, Inc.
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 Cryptec Systems, Inc. filed Critical Cryptec Systems, Inc.
Publication of WO2001016707A1 publication Critical patent/WO2001016707A1/fr

Links

Classifications

    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms 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/10—Mechanisms 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/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment 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/355—Personalisation of cards for use
    • G06Q20/3552—Downloading or loading of personalisation data

Definitions

  • the present invention relates to the field of portable tokens, such as smart cards. More particularly, the present invention relates to a smart card having a true operating system (OS).
  • the OS may be used in conjunction with an application programming interface (API) indexing a set of common OS functions, and/or a hardware abstraction layer (HAL) defining an interface between the OS and the smart card microprocessor.
  • API application programming interface
  • HAL hardware abstraction layer
  • the cardholder desires to use the stored value card to purchase goods or services
  • the card is presented at the point of sale and the cost of the goods or services is deducted from the value of the card.
  • the cardholder may continue to use the stored value card in this manner until all the value has been removed from the card.
  • the card may then be discarded, or its value may be replenished.
  • Such cards are commonly used to pay subway fares or to make long distance phone calls.
  • smart cards For many types of transactions, however, the current trend is away from credit/debit cards and stored value cards, and into a class of devices generally called smart cards. Rather than employing information encoded on a magnetic strip, smart cards include a microprocessor and a memory element embedded within a credit card size device. With a microprocessor, smart cards are able to interact with terminals across a broader range of transactions, and are able to communicate a broader, and a more detailed range of information regarding the cardholder, a cardholder account, transaction authorization, or other information.
  • Smart card is used throughout as a convenient name for a broad class of devices sometimes referred to as portable tokens. Smart cards are the most common present form of portable tokens, but as will be seen hereafter the actual physical form of the portable token, as well as the specific means by which the portable token communicates data to the outside world are not the subject of the present invention.
  • FIG 1 shows an exemplary smart card 10. Roughly the size of a credit card, smart card 10 includes a microprocessor 12 with an integral memory element, and conductive contacts 13. Microprocessor 12 is typically a single wafer integrated circuit mounted on, or embedded within the otherwise plastic smart card. Conductive contacts 13 interface with a terminal to electrically transfer data between the terminal and the smart card. Other embodiments of the smart card do not include conductive contacts 13. Such "contactless" smart cards receive information via proximately coupling, such as magnetic coupling, or via remote coupling, such as radio communication.
  • microprocessor 12 and conductive contacts 13 of Fig 1, are shown in some additional detail in Fig 2.
  • Conductive contacts variously include power contacts, at least one input/output (I/O) port, a reset port, and a clock (elk) signal port.
  • Microprocessor 12 comprises a central processing unit (CPU) 21 which is generically control logic including I/O circuitry 23. Terminal signals variously interface with CPU 21 through the conductive contacts 13 and I/O circuitry 23.
  • Microprocessor 12 is associated with a memory element 20.
  • the memory may be formed on the same integrated circuit as the microprocessor, or may be formed on a separate device.
  • the memory includes Random Access Memory (RAM) 22, Read Only Memory (ROM) 24, and Read/Write memory, such as an Electrically Erasable Programable Read Only Memory (EEPROM) 26.
  • RAM Random Access Memory
  • ROM Read Only Memory
  • EEPROM Electrically Erasable Programable Read Only Memory
  • some or all of these presently -used memory elements may be replaced by battery backed-up RAM, flash memory, or other electronic data storage media.
  • Terminal broadly indicates any device exchanging information with a smart card using any number of data transfer means.
  • a computer, ATM, merchant point-of-sale device, or security control device, are present examples of terminals.
  • the terminal nominally includes a mechanism detecting the presence of a properly positioned smart card.
  • the terminal Upon detecting the smart card, the terminal provides power to the microprocessor, and typically sends a reset (RST) signal to the smart card.
  • RST reset
  • the smart card uses the RST signal to reset itself, or to initiate an internal reset function. After reset, the smart card returns an answer-to-reset (ATR) signal to the terminal.
  • the ATR signal communicates basic information concerning the smart card to the terminal. Once such basic information is successfully recognized by the terminal, communication, i.e., data transfer, between the smart card and the terminal can be established.
  • Smart cards can be programmed to operate as stored value cards, credit cards, debit cards, ATM cards, calling cards, personal identity cards, critical record storage devices, etc.
  • a smart card may, at least in theory, be designed to use a number of different application programs.
  • an inability to readily develop applications has limited the type and number of applications placed on the conventional smart card.
  • most conventional smart cards include only a single application, or at most a single type of application.
  • first generation smart cards are little more than an embedded application.
  • Fig 3A such first generation cards can be viewed as an application 30 stored in memory which runs a set of microprocessor-specific instructions on hardware resources
  • hardware resources is used to generically indicate the memory and logic circuits, with their associated interfaces, used to execute microprocessor instructions but may also include I/O circuits, power circuits, and the other hardware. Given the structure shown in Fig 3 A, each application must be written in a very low level, or machine level language. This language is specific to the microprocessor on which the application is intended to run.
  • the first generation, embedded application programming model offers at least one significant advantage - programming flexibility.
  • Microprocessors are typically able to execute a significant set of instructions. Since an embedded application is written at the machine level, the full range of the microprocessor's instructions set may be accessed and utilized by the application. Unfortunately, such programming flexibility comes at a high price. In order to run an existing application on a different microprocessor, it must often be completely rewritten. Debugging, updating, and testing of embedded applications are arduous. Further, machine level programming is difficult and requires a great deal of hardware specific expertise. Embedded programmers are, thus, hard to find and expensive to retain.
  • a true operating system does not execute commands received from the outside world.
  • a true operating system will not (is unable to) execute commands received from a terminal.
  • an operating system serves as a conduit and router for commands communicated from a terminal to an application stored on the smart card.
  • an operating system serves as a conduit through which an application utilizes the hardware resources.
  • an operating system provides I/O functions and provides other functionality to applications running on the OS. Since first generation smart cards store only the application code, and since this code must necessarily executes commands received from the terminal, first generation smart cards do not include an operating system.
  • second generation smart cards incorporate an interpreter.
  • An interpreter can be thought of as a library of commands. JAVA and
  • BASIC are common interpreters.
  • a set of commands is defined and identified in the interpreter, any one of which may be "called” by an application.
  • the term “call” or “calling” is used throughout to broadly describe a relationship between two pieces of code in which one piece invokes the other. Commands, functions, definitions and instructions may be used by having one piece of code call another pieces of code. The foregoing pieces of code may reside within the an application or the OS.
  • an interpreter 33 can be thought of residing between application 30 and hardware resources 32, as shown in Fig 3B.
  • an application running on a second generation smart card gains access to the hardware resources only through the interpreter which converts a command into one or more microprocessor instructions.
  • the interpreter effectively provides a higher level of abstraction and a programming language reflecting this level of abstraction with which a broader class of programmers may effectively write applications.
  • the definition of commands by the interpreter which promotes programming efficiency and standardization, necessarily restricts programing flexibility, since an interpreter will never define the entire range of commands theoretically made possible by an unrestricted combination of the microprocessor instructions.
  • programming flexibility is traded away for programming ease and standardization.
  • the use of an interpreter also slows program execution since commands must be converted into microprocessor instructions before execution.
  • conventional smart cards implement the file structure defined by
  • ISO-7816, part 4 the use of an interpreter come as an additional penalty to programming flexibility. That is, ISO-7816, part 4 already confines an application programmer to a certain command set used to define a standard file architecture. On top of this restriction, the interpreter further confines the programmer to another fixed set of commands. If a particular functionality is not defined by a command in the interpreter's library, the functionality can not be implemented within an application.
  • the present invention eliminates the trade-off between programming flexibility and programming efficiency which characterizes the conventional smart card. Rather, the present invention allows smart card programmers to utilize the full range of microprocessor instructions, with the attendant advantages in execution speed and programming flexibility, while at the same time having available a sophisticated set of operating system (OS) defined functions.
  • OS operating system
  • the OS functions may be further defined or indexed in an application programming interface (API).
  • API application programming interface
  • the API provides all the benefits of an interpreter without its limitations. Like an interpreter, the API indexes a set of commands.
  • Applications running on a smart card according to the present invention may use the API to call functions resident in the OS. However, unlike conventional interpreters, use of the API is not mandatory. Further, unlike conventional smart card interpreters, the API may be modified in the field. In a smart card system according to the present invention, application programming is no longer held hostage to the particular type of microprocessor being used. Applications need not be written in machine language, nor need they be written in different forms to run on different microprocessors. In fact, applications may be written with reference to only the API and/or to the OS. Analogous to the API's relationship between the applications and the OS, the present invention also provides a hardware abstraction layer (HAL) which defines an interface between the OS and the hardware resources of the smart card. The HAL allows abstraction of the OS away from a specific microprocessor.
  • HAL hardware abstraction layer
  • the present invention provides a smart card system receiving a command from a terminal, the system comprising: a microprocessor capable of executing N instructions, and a memory, an operating system (OS) stored in the memory and defining a set of M functions, wherein each one of the M functions comprises one or more of the N instructions, an application programming interface (API) stored in the memory and indexing a set Q of the M functions, where Q is less than or equal to M, and at least one application stored in the memory and capable of executing the command by calling a function in the set of Q functions through the API, calling a function in the set of M functions through the OS, and directly executing at least one of the N instructions on the microprocessor.
  • OS operating system
  • API application programming interface
  • the present invention provides a smart card receiving N commands from a terminal, the smart card comprising; a microprocessor, and a memory storing an operating system (OS) defining a set of M functions, and storing first and second applications, wherein the first application executes at least one of the N commands by consistent call to the set of M functions through the OS, and wherein the second application directly executes at least one the N commands in the microprocessor without call to the OS.
  • OS operating system
  • the present invention provides a method of executing commands in a smart card, the smart card comprising a microprocessor capable of executing a set of instructions, and a memory storing an application and an operating system (OS), the OS defining a plurality of functions, the method comprising; receiving a command, and if the command is defined in the application in terms of one or more functions in the plurality of functions, executing the command by call to the one or more functions through the OS, while if the command is defined in the application in terms of one or more instructions in the set of instructions, directly executing the command on the microprocessor without call to the OS.
  • OS operating system
  • the present invention provides a method of executing commands in a smart card, the smart card comprising a microprocessor capable of executing a set of instructions, and a memory storing an application, an operating system (OS) defining a plurality of functions, and a hardware abstraction layer (HAL) defining an interface between the OS and microprocessor.
  • the method comprising; first receiving a command, and if the command is defined in the application in terms of one or more functions in the plurality of functions, then calling the one or more functions through the
  • Fig. 2 shows the integrated circuit portion of the exemplary smart card of Fig 1 in some additional detail
  • Fig. 3 A illustrates the software/hardware relationship of a conventional, first generation smart card
  • Fig. 3B illustrates the software/hardware relationship of a conventional, second generation smart card
  • Fig. 4 illustrates the software/hardware relationship of a smart card according to one aspect of the present invention.
  • Fig. 5 illustrates the software/hardware relationship of a smart card according to another aspect of the present invention.
  • one aspect of the present invention can be viewed as having a software/hardware relationship like that shown in Fig 4.
  • one or more applications 40 are stored in memory and are capable of running on a smart card either through an operating system (OS) 44 or directly on the hardware resources.
  • OS operating system
  • the smart card system may also include an application programming interface (API) 42 interposed between application(s) 40 and OS 44 which runs on hardware resources 46.
  • API application programming interface
  • the OS is said to implement or define a number of "functions.”
  • functions should not be read as denoting only classic functionally programming operations, such as "MOVE,” "STORE,”
  • LOOP LOOP
  • instructions s are used to indicate programming code which may be directly implemented or executed in the hardware resources without interpretation or processing by another piece of code, such an interpreter or an OS.
  • an OS function is defined by a collection or sequence of instructions.
  • an OS function might consist of only a single microprocessor instruction, or an OS function might be nothing more than a particular variable definition.
  • the term "function(s)," as used throughout, should be construed as something having relation to or a definition within the OS.
  • the API further defines, or indexes, the OS functions, or more preferably a subset of the OS functions.
  • the API forms a library of favorite, or most commonly used functions callable by applications on the smart card.
  • the API is "glue" between the application(s) 40 and OS 44.
  • one or more OS functions may be called through the API.
  • the API may be thought of as a vector table in which OS functions are immediately cross-referenced with an address in memory to the code implementing the function.
  • Any application written for the smart card may make use of the API, but unlike the conventional smart card employing an interpreter, the application is not required to operate within the set of functions indexed within the API.
  • the API thus, provides an efficiency resource defining certain standard functions, without constraining an application to the use of only the standard functions.
  • An API allows shared data objects to be defined which may be referenced by any application running on the smart card.
  • the API index of functions provides a reference for programmers during development of an application. As such, standardization and consistency of use are obtained. Further, the API provides an additional level of programming abstraction above the OS.
  • command is used throughout to denote a data transaction between a terminal and a smart card application.
  • the OS can not execute a command. Rather, the OS facilitates transmission of the command from a terminal to the application.
  • the command may result in one or more calls to the OS for certain functions. One or more of these calls may be made through the API, or may be made directly to the OS for functions which are not indexed within the API.
  • a smart card application may be stored in native form. That is, the application may, in whole or in part, be complied down to machine executable object code capable of running directly on the hardware resources of the smart card without any call to the OS.
  • first generation smart card would require a significant rewrite of the application.
  • first generation smart cards run on a fixed, embedded version of application X
  • all existing smart cards must be replaced with new cards in order to implement an upgraded version of the application X including the new function.
  • Conventional second generation smart cards can not implement the new function because the existing inte ⁇ reter does not define it.
  • a new version of the interpreter must be written and downloaded onto each card. Since second generation smart cards store the interpreter in ROM, and generally lack a mechanism to perform field downloads, particularly in relation to an interpreter, such cards must be physically replaced in the field in order to provide customers with the upgraded version of application X.
  • the option of having an upgraded application X bypass the OS to directly execute the new function in the microprocessor is particularly profound.
  • the party owning and/or administering application X may not be the same party owning the OS, and/or the smart card.
  • the owner of application X may lack the ability or authorization to amend the OS.
  • the new function may be highly proprietary and as such the owner of application X may not wish to disclose the function to the OS or smart card provider.
  • application X may be upgraded in the field to incorporate code, which when directly executed on the microprocessor, provides the new function without call to the OS.
  • code which when directly executed on the microprocessor, provides the new function without call to the OS.
  • Such limited amendment of application X leaves all other applications on the smart card and the smart card OS untouched. That is, the OS need not be modified to implement the new function. As a result, the relationship between the OS and all other applications stored on the smart card is not altered.
  • the OS might be upgraded to define the new function, and thereafter the API might be amended to index the new function.
  • the OS and one or more applications are stored in ROM. Additional applications may be stored in Read/Write memory, but at least the initial bulk of the applications are stored in ROM.
  • This embodiment is presently preferred on a cost basis, but it is recognized that as the performance characteristics and relative cost of various memory types, i.e., as between ROM, EEPROM, and their substitutes like Flash, change over time this preference may also change.
  • the smart card application or applications stored in ROM must include or consist of at least a "boot-program" capable of downloading data and installing an application from a terminal.
  • This minimal application requirement exists because the OS is a true OS, i.e., one incapable of directly executing a command received from the terminal.
  • the command must go somewhere for execution.
  • some minimal boot-program application must exist to receive and execute the initial command. Otherwise, the OS would merely cycle in a loop looking for the command's owner.
  • the use of a true OS eliminates the possibility of an OS "back- door" which may be misused by a smart card hacker.
  • only the minimal boot-program is stored in ROM with the OS. All other applications are stored in Read/Write memory.
  • the OS and applications are stored in Flash, with some portion of EEPROM being available for use within the smart card system.
  • FIG. 5 Another aspect of the present invention is illustrated in Fig. 5.
  • the applications 40, API 42, OS 44 and hardware resources 46 are as described above with reference to Fig. 4.
  • a Hardware Abstraction Layer (HAL) 50 has been added.
  • the HAL may be thought of as being inte ⁇ osed between the OS and the hardware resources.
  • the OS interfaces with the hardware resources through the HAL in the same manner as applications interface with the OS through the API.
  • the HAL is typically written in assembly code and defines "how" a function is executed in the hardware resources.
  • the OS may indicate the function of "Get byte Z.”
  • the HAL will indicate one or more microprocessor instructions which define a statement saying, in effect, "On this particular microprocessor, the function 'get byte Z' is implemented by use of the following sequence of instructions.” In so doing, the HAL may inco ⁇ orate a card management system provided by the microprocessor.
  • the HAL allows the OS to abstract away from a specific type of hardware. In effect, the OS becomes less sensitive, and perhaps completely insensitive, to the hardware environment of the smart card. As the OS becomes more generic, programming efficiency increases. In fact, since the hardware environment becomes largely irrelevant to the OS as well as the applications, the HAL allows an OS as well as applications to be developed on a desktop computer. Such an ability dramatically facilitates the development of code.
  • the present invention provides a software/hardware relationship between the applications, operating system, and hardware resources of a smart card which facilitate efficient program development while maintaining programming flexibility.
  • the addition of an application programming interface and/or a hardware abstraction layer allows increased abstraction of applications and the operating system, respectively.
  • the present invention creates within the field of smart cards a program development and execution environment more closely approximating that of the desktop computer. With these advances, an expanded set of programmers will be able to efficiently develop a broader range of competent smart card applications.

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)

Abstract

L'invention concerne un token portable, notamment une carte à puce, comportant un système d'exploitation (44). Ce système d'exploitation peut comporter une interface applicative (42) indexant une pluralité de fonctions de système d'exploitation ou un couche d'abstraction matérielle (50) définissant une interface entre le système d'exploitation et les ressources matérielles (46) de la carte à puce.
PCT/US2000/000078 1999-08-31 2000-01-05 Système d'exploitation de cartes à puce doté d'interfaces WO2001016707A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US38629099A 1999-08-31 1999-08-31
US09/386,290 1999-08-31

Publications (1)

Publication Number Publication Date
WO2001016707A1 true WO2001016707A1 (fr) 2001-03-08

Family

ID=23524981

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2000/000078 WO2001016707A1 (fr) 1999-08-31 2000-01-05 Système d'exploitation de cartes à puce doté d'interfaces

Country Status (1)

Country Link
WO (1) WO2001016707A1 (fr)

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6824064B2 (en) 2000-12-06 2004-11-30 Mobile-Mind, Inc. Concurrent communication with multiple applications on a smart card
EP2112595A2 (fr) 2008-04-23 2009-10-28 Giesecke & Devrient GmbH Support de données portatif
CN105592007A (zh) * 2014-10-23 2016-05-18 广东华大互联网股份有限公司 一种层级式智能卡公共应用安全认证系统
US9607189B2 (en) 2015-01-14 2017-03-28 Tactilis Sdn Bhd Smart card system comprising a card and a carrier
US10037528B2 (en) 2015-01-14 2018-07-31 Tactilis Sdn Bhd Biometric device utilizing finger sequence for authentication
US10395227B2 (en) 2015-01-14 2019-08-27 Tactilis Pte. Limited System and method for reconciling electronic transaction records for enhanced security

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4868376A (en) * 1987-05-15 1989-09-19 Smartcard International Inc. Intelligent portable interactive personal data system
US5535416A (en) * 1993-02-12 1996-07-09 International Business Machines Corp. Method for allowing application program in computer system to access device directly in exclusive mode by bypassing operating system and blocking requests from other programs
US5887169A (en) * 1996-03-15 1999-03-23 Compaq Computer Corporation Method and apparatus for providing dynamic entry points into a software layer

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4868376A (en) * 1987-05-15 1989-09-19 Smartcard International Inc. Intelligent portable interactive personal data system
US5535416A (en) * 1993-02-12 1996-07-09 International Business Machines Corp. Method for allowing application program in computer system to access device directly in exclusive mode by bypassing operating system and blocking requests from other programs
US5887169A (en) * 1996-03-15 1999-03-23 Compaq Computer Corporation Method and apparatus for providing dynamic entry points into a software layer

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
FERTITTA K, MEACHAM B: "DEVELOPING PORTABLE TEST PROGRAM SETS IN A GRAPHICAL DESIGN ENVIRONMENT", 1997 AUTOTESTCON PROCEEDINGS: IEEE SYSTEMS READINESS TECHNOLOGY CONFERENCE. ANAHEIM, SEPT. 22 - 25, 1997., NEW YORK, IEEE., US, vol. CONF. 33, 22 September 1997 (1997-09-22), US, pages 475 - 487, XP002929001, ISBN: 978-0-7803-4163-0, DOI: 10.1109/AUTEST.1997.633661 *
LOUCKS L, MANIKUNDALAM R, RAWSON F L: "A MICROKERNEL-BASED OPERATING SYSTEM FOR PERSONAL DIGITAL ASSISTANTS", PROCEEDINGS OF THE WORKSHOP ON WORKSTATION OPERATING SYSTEMS., XX, XX, 1 January 1993 (1993-01-01), XX, pages 09 - 13, XP002928908, DOI: 10.1109/WWOS.1993.348180 *

Cited By (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6824064B2 (en) 2000-12-06 2004-11-30 Mobile-Mind, Inc. Concurrent communication with multiple applications on a smart card
EP2112595A2 (fr) 2008-04-23 2009-10-28 Giesecke & Devrient GmbH Support de données portatif
DE102008020343A1 (de) 2008-04-23 2009-10-29 Giesecke & Devrient Gmbh Portabler Datenträger
CN105592007A (zh) * 2014-10-23 2016-05-18 广东华大互联网股份有限公司 一种层级式智能卡公共应用安全认证系统
US9607189B2 (en) 2015-01-14 2017-03-28 Tactilis Sdn Bhd Smart card system comprising a card and a carrier
US10037528B2 (en) 2015-01-14 2018-07-31 Tactilis Sdn Bhd Biometric device utilizing finger sequence for authentication
US10147091B2 (en) 2015-01-14 2018-12-04 Tactilis Sdn Bhd Smart card systems and methods utilizing multiple ATR messages
US10223555B2 (en) 2015-01-14 2019-03-05 Tactilis Pte. Limited Smart card systems comprising a card and a carrier
US10229408B2 (en) 2015-01-14 2019-03-12 Tactilis Pte. Limited System and method for selectively initiating biometric authentication for enhanced security of access control transactions
US10275768B2 (en) 2015-01-14 2019-04-30 Tactilis Pte. Limited System and method for selectively initiating biometric authentication for enhanced security of financial transactions
US10395227B2 (en) 2015-01-14 2019-08-27 Tactilis Pte. Limited System and method for reconciling electronic transaction records for enhanced security

Similar Documents

Publication Publication Date Title
US6390374B1 (en) System and method for installing/de-installing an application on a smart card
US6256690B1 (en) System and method for facilitating multiple applications on a smart card
US6338435B1 (en) Smart card patch manager
US6808111B2 (en) Terminal software architecture for use with smart cards
Chen Java card technology for smart cards: architecture and programmer's guide
US6910638B2 (en) Smart card that can be configured for debugging and software development using secondary communication port
US6547150B1 (en) Smart card application development system and method
US8881119B2 (en) Computer program product containing instructions for providing a processor the capability of executing an application derived from a compiled form
US20050188360A1 (en) Method and apparatus for providing an application on a smart card
US6761319B2 (en) Configuration of IC card
WO1998052153A2 (fr) Carte a circuit integre avec fonction interpreteur
Faraj et al. Investigation of Java Smart Card Technology for Multi-Task Applications
EP1575005B1 (fr) Procédé et dispositif pour le traitement d'un identificateur d'application issu d' une carte à puce
EP1053535B1 (fr) Configuration de carte a circuit integre
AU716558B2 (en) Portable, secure transaction system for programmable, intelligent devices
WO2001016759A1 (fr) Systeme et procede de gestion de memoire de carte a puce
WO2001016707A1 (fr) Système d'exploitation de cartes à puce doté d'interfaces
EP0955578A1 (fr) Procédé et dispositif pour effectuer une fonction assignée à un code d'instruction
US8533747B2 (en) Method and system for selecting one or more integrated circuit card interface devices
JP3515417B2 (ja) 非持続メモリ内にオブジェクトを作成する方法および装置、ならびにオブジェクトへのアクセス可能性を維持する方法
WO2003021428A1 (fr) Procede et dispositif permettant de relier des fichiers applet convertis
WO2001016865A1 (fr) Systeme et procede d'installation/desinstallation d'une application sur une carte a puce
WO2001016873A1 (fr) Gestionnaire de correcteur de carte a puce
WO2001016874A1 (fr) Gestionnaire de transactions de carte a puce
Fort Smart card application development using Java Card Technology

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): SG

AL Designated countries for regional patents

Kind code of ref document: A1

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

121 Ep: the epo has been informed by wipo that ep was designated in this application
DFPE Request for preliminary examination filed prior to expiration of 19th month from priority date (pct application filed before 20040101)
122 Ep: pct application non-entry in european phase