Posts Tagged ATR
In this model, we assume OCF (OpenCard Framework) and the smartX engine are initially installed and configured on the target terminal. As explained in the previous section, the terminal application consists in two blocks: the application process and the application protocol. The application process that encapsulates the logic of the application is compiled into a Java applet signed by a trusted entity. The application protocol is described inside an SML dictionary and is card-specific. Once the Java applet is downloaded, the smartX engine identifies the smart card inserted in the terminal. A simple identification consists in verifying the historical bytes of the card ATR (Answer To Reset). After correct identification, the smartX engine dynamically downloads the SML dictionary that contains the application protocol for the card inserted inside the terminal. With this dynamic mechanism, you minimize the loading time since you only download the dictionary relevant to the card inside the terminal.
In the OCF model, you had to download with the applet all the CardService implementations. With smartX, a terminal is also not limited to a predefined set of smart cards. As long as you provide the correct SML dictionary, a terminal can dynamically accept a new smart card that was not originally supported by the application. All these advantages make smartX a platform of choice for developing and deploying smart card applications on the Internet.