US007232073B1
`
`a2) United States Patent
`US 7,232,073 Bl
`(10) Patent No.:
`
`(45) Date of Patent: Jun. 19, 2007
`de Jong
`
`(54) SMART CARD WITH MULTIPLE
`APPLICATIONS
`
`(75)
`
`(73)
`
`Inventor: Eduard de Jong, Dyfed (GB)
`
`Assignee: Sun Microsystems, Inc., Santa Clara,
`CA (US)
`
`(*)
`
`Notice:
`
`Subject to any disclaimer, the term ofthis
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 380 days.
`
`(21)
`
`Appl. No.:
`
`11/019,833
`
`(22)
`
`Filed:
`
`Dec. 21, 2004
`
`2003/0078866 Al
`2003/0212896 Al
`
`............. 705/35
`4/2003 Richards et al.
`11/2003 Kisliakov ......... 713/193
`
`2004/0024735 Al
`2004/0255081 Al
`2005/0038741 Al
`2005/0091544 Al
`2005/0097550 Al
`2005/0138354 Al
`2005/0149926 Al
`2005/0178833 Al*
`
`2005/0184163 Al
`2005/0184164 Al
`2005/0188360 Al
`
`2/2004 Yap et al. 0... ee 07/1
`12/2004 Arnouse..........
`. TLV/1IS
`2/2005 Bonalle et al.
`.....
`w+ 705/40
`4/2005 Lambert
`.............
`. 713/202
`5/2005 Schwabeetal. ............ TINT
`6/2005 Saltz oo... eee sees 713/153
`T2005 SaltZ .....eece cess eseeeees T18/1
`8/2005 Kisliakov «0.0.0... 235/441
`
`
`
`8/2005 de Jong ....... eee 235/492
`8/2005 de Jong ....... eee 235/492
`8/2005 de Jong ....... eee 717/136
`
`Int. Cl.
`G06K 19/00
`(2006.01)
`Sun Microsystems, Inc., “Java Card™ 2.2 Runtime Environment
`|OA©) 235/487; 235/494; 235/382;
`(52)
`(JCRE) Specification”, Palo Alto, CA, pp. 1-110,
`[Online] Jun.
`711/115; 717/163
`2002. (XP002325473).
`Field of Classification Search................ 235/382,
`Sun Microsystems, Inc., “Java Card™ 2.2 Application Program-
`235/487, 494; 711/115; 717/163
`ming Interface”, Palo Alto, CA, pp. 1-90,
`[Online] Sep. 2002.
`See application file for complete search history.
`(XP002325474).
`References Cited
`
`OTHER PUBLICATIONS
`
`(Continued)
`
`Primary Examiner—Karl D. Frech
`(74) Attorney, Agent, or Firm—Gunnison, McKay &
`Hodgson, L.L.P.; Forrest Gunnison
`
`(57)
`
`ABSTRACT
`
`One embodiment of the invention provides a smart card
`having multiple applications installed thereon. One of the
`multiple applications is designated as a default application
`which is activated whenever the card is reset. The default
`
`application is required to implementa first operation to
`provide a canonically ordered listing of the multiple appli-
`cations on the card. The default application may further
`implement a second operation to allow one of the multiple
`applications to be selected for activation via an index into
`the listing.
`
`(51)
`
`(58)
`
`(56)
`
`U.S. PATENT DOCUMENTS
`
`
`
`... 235/380
`Taylor .....
`w 395/241
`Pitroda ....
`Claus et al. wee 704/33
`Tushie et al. we 726/26
`Chan et al. wee 380/25
`Bradley et al.
`....
`... 235/492
`
`Brake, Jr. et al. ........... 705/41
`Hohle et al. we 705/1
`Hohle ...........
`... 235/492
`
`Wilkinson et al.
`............. T17/5
`
`Carperet al.
`......
`... 235/492
`Delo et al. wee TWA
`....
`.. 717/126
`Yellin et al.
`
`Wentker et al.
`.
`... 235/492
`
`Blossom ........::eeeeeeeeeee 235/492
`Kisliakov oo... eee 235/492
`Ashizawa et al.
`.
`... 235/492
`
`......0... 713/172
`Lagosanto et al.
`Ashizawa et al.
`.......... 235/492
`
`6/1996
`12/1996
`1/1999
`3/1999
`12/1999
`2/2000
`2/2000
`8/2000
`3/2001
`10/2001
`5/2002
`7/2002
`11/2002
`11/2002
`10/2003
`7/2005
`12/2005
`6/2002
`9/2002
`
`ok
`
`AAAAAAAAB
`
`l
`Bl
`Bl
`Bl
`Bl
`B2
`B2
`B2
`B2
`Al
`Al
`
`5,530,232
`5,590,038
`5,857,079
`5,889,941
`6,005,942
`6,024,286
`6,032,136
`6,101,477
`6,199,762
`6,308,317
`6,390,374
`6,418,554
`6,477,702
`6,481,632
`6,631,849
`6,915,957
`6,976,635
`2002/0083322
`2002/0134843
`
`69 Claims, 15 Drawing Sheets
`
`i
`
`
`
`
`Default Applet requests list
`from Card Executive Layer
`702
`
`Card Executive Layer
`accesses Application Listing
`704
`
`Card Executive Layer
`creates canonically ordered
`tist 706
`
`Card Executive Layer
`returns canonically ordered
`list to Default Applet 708
`
`{q
`
`i
`iit
`|
`
`:
`|
`'
`
`1
`
`SAMSUNG 1018
`
`SAMSUNG 1018
`
`1
`
`

`

`US 7,232,073 B1
`Page 2
`
`OTHER PUBLICATIONS
`
`Sun Microsystems, Inc., “User’s Guide, Wireless Toolkit, Version
`2.1, Java™ 2 Platform, Micro Edition”, Sana Clara, CA, pp. 7-17,
`73-75, [Online] Dec. 2003. (XP002325476).
`
`“OSS Through
`OSS-J Architecture Board,
`Through
`Java™,
`Design Guidelines”, OSS
`[Online] Oct. 31, 2001. CXP002325475).
`
`Java™ J2EE
`pp.
`1-116,
`
`* cited by examiner
`
`2
`
`

`

`U.S. Patent
`
`Jun. 19, 2007
`
`Sheet 1 of 15
`
`US 7,232,073 B1
`
`Create Java Card
`
`210
`
`
`
` Preload
`Applications
`
`
`
`215
`220
`
`
`issue Card
`
`(Personalisation)
`
`
`
`Add/Remove
`
`Use Card
`
`Applications
`
`
`230
`235
`
` Terminate Card
`
`
`240
` Figure 1
`
`3
`
`

`

`U.S. Patent
`
`Jun. 19, 2007
`
`Sheet 2 of 15
`
`US 7,232,073 B1
`
`aiy/uonesiddy
`
`
`
`Le}s0zeuadg
`
`
`
`NVAWNV192uUs9}U|
`
`OcL
`
`O€L
`
`
`
`a01IOyoegLL}40}e190d0
`
`JEUILWUIO|
`
`jeusua|
`
`ObL
`
`zaunbiy
`
`801Nddav
`
`LOL42pjoHpueg
`
`
`
`puegyeulg
`
`ZOL
`
`4
`
`
`
`
`
`

`

`U.S. Patent
`
`Jun. 19, 2007
`
`Sheet 3 of 15
`
`US 7,232,073 B1
`
`TERMINAL 140
`
`CARD 102
`
`
`
`
`Detect Card Insert
`162
`
`Activate Card
`‘4
`
`
`
`
`
`
`
`
`
`
`
`
`
`Card is Activated
`172
`
`
`
`Determine
`
`Application to
`launch 165
`
`
`
`
`
`Request
`Application by AID
`
`166
`
`
`
`
`Receive Request
`174
`
`
`
` Identify
`
`Yes
`
`
`Launch matching
`
`.°
`
`Matching
`Application 177
`
`
`
`Return indication
`
`Receive indication
`
`
`
`of success/failure
`180
`
`179
`
`
`
`Figure 2A
`
`5
`
`

`

`U.S. Patent
`
`Jun. 19, 2007
`
`Sheet 4 of 15
`
`US 7,232,073 B1
`
`TERMINAL110
`
`CARD 102
`
`Detect Card Insert
`162
`
`
`
`
`
`
` Activate Card
`
`
`Card is Activated
`164
`172
`
`
`
`
`
`Determine
`
`Application to
`launch 165
`
`
`
`
`
`Request
`
`
`
`Receive Request
`
`
`Application by
`
`
`partial AID 166
`
`
`
`Identify
`
`firstinext Matching
`
`
`176A ?
`
`
`
`
`
`
`Launch matching
`Application 177
`
`=z9°
`
`
`
`
`
`Return indication
`
`
`Receive indication
`of success+tAID or
`
`
`180
`
`failure 179A
`
`
`
`
` Desired
`
`
`
`Application
`183 ?
`
`
`
`Application
`Launched
`182?
`
`Figure 2B
`
`Yes
`¥
`
`Nlo
`¥
`
`Proceed with
`Session 185
`
`Terminate Session
`184
`
`6
`
`

`

`U.S. Patent
`
`Jun. 19, 2007
`
`Sheet 5 of 15
`
`US 7
`
`2
`
`232,073 B1
`
`ALOPCiv
`
`bzyalddy
`
`
`
`10}9a/9Sja\ddy
`
`CLP
`
`OfEIdVPAeDBAe
`
`alseayiddyGyajddy ¢ainbi4
`feoLLL:Wo9eWW[lemedty:
`pueWOU‘WV-Aioway
`aboraiv;|——s;-'||ovovaiv :|atoratvVLOdiv
`OZEJUSWUOAUZaUj-uNYpaegBAL
`
`ELEOla1ydes6o}dAig
`
`
`JoseTemaswoge©Hema
`oywiddy|2||aiiddyVvieiddy
`o1seaaisevise
`
`
`
`
`COLPADever
`
`vLéWOYd33
`
`zLesuojoun
`
`
`
`8be4aAe7]BAIWNDaXKypueg
`
`uojesi|ddy
`
`ceSUBST]
`
`7
`
`
`
`

`

`U.S. Patent
`
`Jun. 19, 2007
`
`Sheet 6 of 15
`
`US 7,232,073 B1
`
`
`
`VLS¢JIddy
`
`VLOPdiv
`
`asejaiddy
`
`agboraiv
`
`divAxolg
`
`49}01d19}u]
`
`VbLL8
`
`divAxolg
`
`49}01d49}U]
`
`aLLs
`
`G0LpAxoig
`
`
`
`Zbb10}99j9gJaIddy
`
`PLYBeqpseD
`
`ezpBuysiqddy
`
`ZOPPABDeAer
`
`yanbi4
`
`
`
`'GOEL291LYOyg
`
`
`
`
`
`VOELS9INO4OeG
`
`VOLPAxold
`
`8
`
`
`

`

`U.S. Patent
`
`Jun. 19, 2007
`
`Sheet 7 of 15
`
`US 7,232,073 B1
`
`Other 502C
`
`Firewall ID 502A
`
`Applet ID 502B
`
`Figure 5
`
`323
`
`AID 401A
`
`AID 401B
`
`AID 401E
`
`AiD 401C
`
`AID 401D
`
`Figure 6
`
`9
`
`

`

`U.S. Patent
`
`Jun. 19, 2007
`
`Sheet 8 of 15
`
`US 7,232,073 B1
`
`323A
`
`f
`
`AID 401A
`
`AID 401B
`
`AID 401C
`
`AID 401D
`
`AID 401E
`
`424
`
`JIN
`
`CD 602
`
`CM603
`
`Figure 6A
`
`10
`
`10
`
`

`

`U.S. Patent
`
`Jun. 19, 2007
`
`Sheet 9 of 15
`
`US 7,232,073 B1
`
`
`
`
`
`
`
`
`
`
`
`AID 401C
`(DF 601)
`
`AID 401A
`(CD 602)
`
`AID 401E
`(CM 603)
`
`AID 401B
`
`AID 401D
`
`Figure 6B
`
`TERMINAL 110
`
`CARD 102
`
`
`Detect Card Insert
`
`
`162
`
`
`772
`
`
`
`Card is Activated
`
`Activate Card
`164
`
`
`Request
`Application List
`
`766
`
`
`
`
`
`
`
`
`Receive Request
`774
`
`Obtain AID list 776
`
`Receive AID list
`
`780
`
`
`Return AID list 779
`
`Figure 7
`
`11
`
`11
`
`

`

`U.S. Patent
`
`Jun. 19, 2007
`
`Sheet 10 of 15
`
`US 7,232,073 B1
`
`
`
`Default Applet requests list
`from Card Executive Layer
`702
`
`
`
`
`
`
`Card Executive Layer
`accesses Application Listing
`704
`
`
`
`Card Executive Layer
`creates canonically ordered
`
`
`
`
`list 706
`
`
`
`Card Executive Layer
`returns canonically ordered
`
`list to Default Applet 708
`
`
`
`
`
`Identify Default
`
`Applet 712
`
`Figure 7B
`
`12
`
`12
`
`

`

`U.S. Patent
`
`Jun. 19, 2007
`
`Sheet 11 of 15
`
`US 7,232,073 B1
`
`AeedieeeEE ERREEEeyETEitd peEERTLLR
`
`Power Up 710
`
`
`
`neseerSLRAddeeeeeecaneeeeennnerenenenersemendsmemnieeynneneswererenenee
`
`
`
`
`
`Launch Default Applet 714
`
`772 d
`
`Figure 7C
`
`13
`
`
`
`Card Executive Layer
`accessesApplication Listing
`704C
`
`
`
`Card Executive Layer
`creates canonically ordered
`list 706C
`
`
`Identify Default Applet 712
`
`
`
`
`
`
`
`
`
`2 |
`
`:
`
`13
`
`

`

`U.S. Patent
`
`Jun. 19, 2007
`
`Sheet 12 of 15
`
`US 7,232,073 B1
`
`TERMINAL 110
`
`CARD 102
`
`Detect Card Insert
`162
`
`ActivateCard
`
`Card is Activated 772
`
`Receive AIDlist 780
`
`Select desired
`application 782
`
`Request application by
`Index 784
`
`Obtain AID list from
`card executive layer
`776D
`
`Supply AID list to
`Terminal
`779D
`
`Receive AID selection
`by Index 790
`
`
`
` Launch SelectedAID.
`
`792
`
`Figure 7D
`
`14
`
`14
`
`

`

`U.S. Patent
`
`Sheet 13 of 15
`
`US 7,232,073 B1
`
`eae aeiaea ei i eee ee ee 4
`
`ccceroooee+eeeeeeeeee Jun. 19, 2007
`pottt
`
`Access RID for each AID in
`received AID listing 820
`
`Derive a Network Resource
`Identifier from each RID 830
`
`Send Requestto Identified
`Network Resources 840
`
`Receive Material over
`network 850
`
`Use Material to Select AID
`from listing 860
`
`Figure 8
`
`15
`
`15
`
`

`

`U.S. Patent
`
`Jun. 19, 2007
`
`Sheet 14 of 15
`
`US 7,232,073 B1
`
`Install application
`900
`
`
`
`
`
`
`Receive requestto
`make default
`
`application 910
`
`
`
`
`
`
`
`Application
`
`has interface ?
`
`920
`
`
`
`
`
`
`
`Continue ?
`940
`
`
`Existing Default
`Applet ? 930
`
`
`
`
`Figure 9
`
`16
`
`

`

`U.S. Patent
`
`Jun. 19, 2007
`
`Sheet 15 of 15
`
`US 7,232,073 B1
`
`
`
`Default Applet Interface 1080
`
`
`
`
`
`1020
`
`List Handler
`1010
`
`Select by Index
`Handler
`
`Applet 351
`
`Command/ADPU
`forwarding API 1050
`
`List Wrapper
`1011
`
`Application
`Listing 323
`
`Selector 412
`
`
`
`
`Select by Index
`Wrapper
`
`1021
`
`
`
`
`Applet
`
`
`
`Card Executive Layer 318
`
`Figure 10
`
`17
`
`17
`
`

`

`US 7,232,073 B1
`
`1
`SMART CARD WITH MULTIPLE
`APPLICATIONS
`
`CROSS-REFERENCE TO RELATED
`APPLICATIONS
`
`The present application is related to the following appli-
`cations, all of which were filed on 24 Feb. 2004 and are by
`the same inventor and assigned to the same assignee as the
`present application:
`“METHOD AND APPARATUS FOR PROVIDING AN
`APPLICATION IDENTIFIER FOR AN APPLICATION
`
`ON A SMART CARD”(Sun P9176—U:S. application Ser.
`No. 10/786,506);
`“METHOD AND APPARATUS FOR INSTALLING AN
`
`APPLICATION ONTO A SMART CARD” (Sun 9177—
`USS. application Ser. No. 10/786,763);
`“METHOD AND APPARATUS FOR SELECTING A
`
`DESIRED APPLICATION ON A SMART CARD” (Sun
`P9178—U.S. application Ser. No. 10/786,895); and
`“METHOD AND APPARATUS FOR PROCESSING AN
`APPLICATION IDENTIFIER FROM A SMART CARD”
`
`(Sun P9179—USS. application Ser. No. 10/786,312).
`The above-identified applications are all hereby incorpo-
`rated by reference into the present application.
`
`20
`
`25
`
`FIELD OF THE INVENTION
`
`The invention relates to smart card technology, and in
`particular to smart cards that support multiple applications.
`
`30
`
`BACKGROUND OF THE INVENTION
`
`Mostpeople now havea collection of small plastic cards,
`representing various credit cards, store cards, identity cards,
`membership cards, and so on. Information about the card
`and its owner, such as account details and so on, is normally
`printed or embossed on the card, and mayalso be stored in
`some form of magnetic strip. Note that such cards are simply
`passive storage devices, and the information that they con-
`tain is fixed at card creation time.
`
`In recent years, smart cards have also proliferated. These
`are similarin scale to traditional credit cards, but incorporate
`within their plastic cases a microelectronic memory and also
`(optionally) an embedded processor. It will be appreciated
`that the computational resources available within a smart
`card are extremely limited compared to those of a desktop
`workstation, or even a laptop or handheld device. One
`especially popular form of smart card is known as a Java
`Card. This is based on the Java platform developed by Sun
`Microsystems (“Java” and “Java Card” are trademarks of
`Sun Microsystems Inc). In such devices, a Java virtual
`machine (VM)is provided within the smart card to allow the
`execution of Java applets or applications. Particular advan-
`tages of being able to use the Java environment for smart
`card applications are the inherent security features of the
`Java environment, plus the ready availability of software
`development packages for the Java programming language.
`It is estimated that by the end of 2002 over 200 million Java
`cards had been shipped. More information about the Java
`Card smart card platform is available from the page: /prod-
`ucts/javacard/ at the web site: http://java.sun.com and from
`the site: http://wwwyavacardforum.org/, and also from the
`book: “Java Card Technology for Smart Cards” by Zhiqun
`Chen, Addison-Wesley, 2000, ISBN 0-201-70329-7.
`An Application Programming Interface (API) is defined
`for the Java Card platform. Applications written in the Java
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`18
`
`2
`programming language invoke this API to access the Java
`Card run-time environment (JRE) and any native services.
`The Java Card API allows application portability, in that the
`same application can run on any smart card that supports the
`API. The Java Card API is compatible with international
`standards, in particular the ISO/IEC 7816 family of stan-
`dards.
`
`In the desktop environment, there is a clear distinction
`between a Java applet and a Java application, in particular
`the absence of a main class from the former. Although there
`is a similar distinction in the smart card environment, applets
`for use on a Java card platform are not the same as applets
`that run on a web browser. Programsthat run on smart cards
`maybereferred to as either an application or as an applet
`(the former term will be used generally herein).
`The Java Card platform supports multiple applications on
`a single card. These applications may be separated by
`firewalls, in order to ensure that they do not interfere with
`one another. This is particularly of concern if the various
`applications are operated by different organisations, whose
`business relationships with the card holder may be indepen-
`dent of one another.
`FIG. 1 is a schematic diagram representing the life cycle
`of a smart card, which in this particular implementation is a
`Java Card. The life cycle commences with the manufacture
`of the card, and the initial loading of the base operating
`system and the Java Card environment (210). Also at this
`stage, one or more applications may be preloaded (215).
`Generally, the base operating system and Java Card envi-
`ronment, and also potentially any preloaded applications,
`may be stored in ROM on the smart card as part of the
`manufacturing process.
`The card is now ready for issue to a card holder (220),
`which typically involves an appropriate personalisation pro-
`cess, as well as initialisation of the Java environment, and
`starting the Java virtual machine on the card. The card holder
`is thereafter able to use the card (230). Note that if the card
`was originally issued without any preloaded applications,
`then the card holder may haveto load an application prior to
`making substantive use of the card. In practice however, this
`situation is rather uncommon,since usually there is at least
`one preloaded application in order to motivate issuance of
`the card in the first place.
`During the operationallifetime of the card, further appli-
`cation programs maypotentially be installed onto the card
`(235), for example if the card holder signs up to new
`accounts or services. Conversely, applications may be
`removed from the card, perhaps because an account
`is
`closed.
`
`The last operation shown in FIG. 1 is where the card is
`terminated (240). This may occur, for example, because the
`card has a built-in expiry date or is surrendered by the user
`(perhaps if the user is moving to a new card issuer, or the
`card is physically damaged).
`FIG. 2 is a high-level schematic diagram illustrating the
`main architectural components in a typical smart card appli-
`cation. Thus smart card 102 belongsto card holder 101. Note
`that smart card 102 may be used as a standalone device, or
`may be incorporated into some larger system such as a
`mobile phone. Smart card 102 interacts with a terminal 110
`by exchanging an application protocol data unit (ADPU)
`108. The format for the ADPUis defined by the International
`Standard ISO/IEC 7816-3 and typically comprises a com-
`mand header portion and a payload portion.
`Terminal 110 may be a handheld device, an adjunct to a
`desktop workstation, a dedicated card reader (analogous to
`an ATM) or any other suitable system. Communications
`
`18
`
`

`

`US 7,232,073 B1
`
`3
`between the smart card 102 and the terminal 110 may be by
`wired connection or by wireless link (e.g. radio or some
`other electromagnetic signal), depending on the particular
`devices concerned. Terminal 110 may be under the direct
`control of an operator 111 (such as for a handheld terminal),
`or alternatively terminal 110 may be automated (such as for
`an ATM). In this latter situation, the card holder 101 may
`operate the terminal 110 himself/herself.
`Terminal 110 interacts with a back office 130 over any
`suitable form of network 120, such as the Internet, a local
`area network (LAN), a wide area network (WAN), and so
`on. Back office 130 may comprise multiple systems (not
`explicitly shown in FIG. 1), such as a webserveror portal
`attached to network 120, perhaps with an application server
`and/or a database system behind. Note that the terminal 110
`may beoff-line until activated by a smart card 102, a card
`holder 101 or a terminal operator 111 to access a back office
`130 over network 120.
`Tt will also be appreciated that in somesituations, terminal
`110 may interact with card 102 without reference to any
`other system (such as back office 130). For example, termi-
`nal 110 might be some form of machine, such as a car or a
`photocopier, and card 102 might be used to control access to
`the machine.
`
`In operation, the card holder 101 typically places the card
`102 into or adjacent the terminal 110, thereby allowing the
`two to interact, e.g. to perform a debit operation from the
`card to purchase some goods. This interaction will generally
`be referred to herein as a session, and normally involves the
`exchange of multiple messages between the smart card 102
`and the terminal 110.
`
`Associated with each applet on smart card 102 is an
`Application Identifier (AID). The AID is a byte string up to
`16 bytes long, whose format is defined by International
`Standard ISO/IEC 7816-4:2004. According to this standard,
`the first 5 bytes or octets of the AID represent the registered
`application provider identifier (RID) and have a valueallo-
`cated by ISO or one of its member bodies. The RID indicates
`the merchant or other entity involved with operating the
`application, hereinafter referred to as the RID operator. The
`RID operator is generally responsible for the back office
`system 130, and is depicted as application/RID operator 131
`in FIG. 2. The last 11 bytes of the AID constitute the
`proprietary application identifier extension (PIX). The PIX
`is determined by the RID operator 131, and can be used to
`store a reference number or other information associated
`with the application.
`International standard ISO/IEC 7816-4 defines a proce-
`dure, namely the Select command, to allow a terminal to
`specify and launch a desired application on a smart card;
`selecting an application determines the start of a session.
`The processing associated with the Select command is
`illustrated at a high level in the flowchart of FIG. 2A. The
`processing starts when the smart card 102is first inserted
`into the terminal 110. The terminal detects the insertion of
`the smart card (162), and in response to such detection
`activates the smart card (164, 172). This activation generally
`includes providing power to the smart card and launching a
`default application on the card. The default application is
`so-called becauseit is automatically started when the card is
`reset, such as on power up. In some implementations, the
`default application is identified as the applet that was most
`recently running on the card (prior to the reset). In other
`implementations,
`the default application may be a fixed
`applet.
`The terminal now determines an application on the card to
`launch (165), and sends a corresponding Select command
`
`4
`using an ADPU 108 to the smart card (166). The ADPU
`specifies the AID of the selected application for use in this
`session. The request from the terminal is received by the
`smart card (174). The request
`is handled by an applet
`selector program that is running on the smart card 102 as
`part of a card executive layer. The applet selector is respon-
`sible for locating the application that matches the AID
`requested from the terminal, 1.e. the application that has the
`same AID asthat specified in the request (176). Ifa matching
`application is found, then this application on the smart card
`is duly launched (177). The smart card now returns to the
`terminal 110 an indication of whether or not the requested
`application has been successfully launched (179 and 180).
`(N.B. This last action is optional within the context of
`ISO/IEC 7816-4, although it is commonly implemented).
`FIG. 2B describes a variation on the processing of FIG.
`2A (also in accordance with ISO/IEC 7816-4). The opera-
`tions in FIG. 2B are the same as described abovein relation
`
`to FIG. 2A until operation 166, in which the terminal 110
`supplies the card with an abbreviated or truncated AID
`(knownas a partial AID). For example, the partial AID may
`comprise the first ten bytes of an AID. In these circum-
`stances, there may be multiple matches against the partial
`AID. For example, if two applications have AIDs that have
`their first ten bytes in common and then differ only in the
`final six bytes of the AID, they will both match the same
`partial AID of length 10 bytes (orless). One reason for using
`a partial AID might be if the terminal 110 wants to identify
`all applications on the card having a particular RID.
`Consequently, at operation 176A (corresponding to opera-
`tion 176 in FIG. 2A), the smart card identifies one of the
`potentially multiple matching applications on the card. This
`application identified at operation 176A represents thefirst
`matching application. The (first) matching application af
`any) on the smart card is now launched (177), and a response
`is provided to the terminal (179A, 180) indicating whether
`or not the partial AID request (176) was successful. If this
`request was successful, then the response 179A also includes
`the AID of the application that was launched at operation
`177. If this AID correspondsto the application desired by the
`terminal (183),
`then session processing continues (185).
`However, if the launched application as indicated by the
`received AID is not the desired application, then processing
`at the terminal loops back to operation 166, whereby another
`request containing the partial AID is sent by the terminal to
`the smart card 102.
`
`The smart card now identifies at operation 176A the next
`application that matches the partial AID, launches this next
`matched application (177), and returns the full AID for this
`next matched application (179A). In addition, the previously
`launched application (i.e.
`the first application) may be
`terminated (not shown in FIG. 2B). The terminal again tests
`at operation 183 to determine whetheror not the matching
`application corresponds to the desired application, and if
`not, then we proceed once again around the above loop.
`The procedure of FIG. 2B therefore terminates either
`when the desired application on smart card 102 has been
`launched, thereby allowing the session to continue (185), or
`there are no more applications on smart card 102 that match
`the partial AID. In other words, the AIDsforall the matching
`applications (if any) have already been returned one-by-one
`at operation 179A,and then rejected at operation 183. In this
`latter case, the smart card fails to find any further matching
`applications(i.e. the test of operation 176Ais negative), and
`returns a failure indication to the terminal at operation 179A.
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`19
`
`19
`
`

`

`US 7,232,073 B1
`
`5
`The terminal then detects that no (further) application has
`been launched on the card (182), and so aborts the session
`(184).
`Note that to support the above processing, the card 102
`needs to ensure thatit selects a different matching AID each
`time it loops through operation 176A (otherwise it may
`return a matching AID that has already been rejected by the
`terminal). One mechanism to ensurethis is for the smart card
`to maintain a list of those matching AIDsthat have already
`been returned to the terminal at any previous loops through
`operation 179A.Alternatively, the smart card may recognise
`someordering of the AIDs (for example, based on the binary
`value of an AID). In this latter case, the smart card notes the
`matching AID sent last time at operation 179A, and for the
`next loop through operation 176Aselects the next matching
`AID in the imposedordering.
`Tt has been suggested that a smart card may include a
`facility to provide a complete list in a canonical orderofall
`the applications installed on the smart card. (This suggestion
`is described in a submission by the Netherlands to the
`standards committee JTC1/SC17 of the ISO/IEC). Each
`application on a smart card is represented in the list by its
`AID. The list could thento be usedin all presentations by the
`card of its applications, for example as a directory file. It is
`also contemplated that the canonically ordered AID list
`could be used in a variation on the Select command as
`
`20
`
`25
`
`6
`location on the card. The development of Java cards has
`introduced an application-oriented environment, in which
`the behaviourof a card is controlled by an application on the
`card. This has led to the role of a default application as
`mentioned above to take initial control of a card, pending
`user selection of a particular desired application. A further
`submission by the Netherlands to the standards committee
`JTC1/SC17 of the ISO/IEC has suggested that a default
`application shouldfirstly be able to provide a list of appli-
`cations on the smart card and secondly to support selecting
`an application on the card to run.
`Although the Java Card environment supports multiple
`applications from different RID operators,
`in practice, a
`large majority of issued cards originate from and are run by
`a single RID operator. In other words, applications from one
`RID operator are typically found on one card, and applica-
`tions from another RID operator are found on a different
`card. Moreover, many cards are provided with only a single
`application. Consequently, relatively little attention has been
`paid to the handling of smart cards having multiple appli-
`cations, potentially from a range of different vendors(i.e.
`from different RID operators).
`
`SUMMARY OF THE INVENTION
`
`In accordance with one embodimentof the invention there
`
`is provided a smart card having multiple applications
`depicted in FIGS. 2A and 2B. In particular, an index to the
`installed thereon. One of the multiple applications is desig-
`list could be encoded over one octet, for instance using
`nated as a default application which is activated whenever
`values 1 to 253, with the applications specified in the order
`the card is reset. The default application is required to
`in which they were originally loaded onto the smart card.
`implementa first operation to provide a canonically ordered
`This would then allow a desired application to be specified
`listing of the multiple applications on the card. In one
`for selection by index value (rather than by AID).
`particular embodiment, an application may be selected for
`Accordingto this proposal, which is especially relevantto
`activation by providing an index into the list in a command
`a Java Card implementation,three particular applications are
`header of an application protocol data unit received by the
`distinguished:
`card from a terminal. This therefore enables an application
`(1) a card management application—this performs func-
`to be selected by index fromalist, rather than by AID.
`tions related to the loading, initialization and removal
`In one particular embodiment, the default application is
`of other applications.
`further required to implement a second operation to allow
`(2) a card holder personal data application—this typically
`one of said multiple applications to be selected for activation
`contains data and functions related to the card holder,
`via an index into saidlist. In one particular embodimentthe
`such as a userprofile, a PIN, biometrics, and name and
`default application has a programming interface to imple-
`address. These functions and data may be accessible in
`mentthe first operation, and the second operation if relevant.
`the card by other applications as appropriate.
`The programming interface comprises a predetermined set
`(3) the default application—discussed above. (Note that a
`of one or more method calls. The programming interface
`card that supports multiple modes of communication
`may compriseat least a first methodcall for enablingthefirst
`with terminal 110 may havea different default appli-
`operation. The programming interface may further comprise
`cation associated with each particular mode of com-
`a second methodcall for enabling the second operation. The
`munication).
`programming interface may also comprise a method for
`notifying an application that it has been designated as the
`default application, and a method for notifying an applica-
`tion that it has ceased to be the default application.
`In one particular embodiment, the list is provided by the
`default application in response to a request from a terminal,
`while in another embodiment, the list is provided automati-
`cally to a terminal by the default application in response to
`activation of the default application. In yet another embodi-
`ment, the default application is configurable as to whether
`the list is provided by the default application in response to
`a request from the terminal or automatically in response to
`activation of the default application. The default application
`mayhave a handler installed to implementthe first operation
`to provide the list.
`In one particular embodiment, there is a card executive
`layer in the smart card, and the default application interacts
`with the card executive layer in order to implementthe first
`operation and the second operation (if relevant).
`
`The card management application and the card holder data
`application are generally preloaded onto a smart card (see
`operation 215 in FIG.1).
`In the proposal, the three special applicationslisted above
`are assigned predetermined index values. In particular, the
`index value 0 is reserved for the current default application;
`the index value -2 (254) is reserved for the card holder data
`application; and the index value -1 (255) is reserved for the
`card managementapplication. Note that the card holder data
`application and the card managementapplication will there-
`fore generally appear twice in the list, once at the position
`in the list that reflects when they were loaded, and once at
`their reserved location (i.e. -2 and -1 respectively). This
`submission has not yet been formally adopted by the ISO/
`TEC.
`
`Mostearly smart cards were viewed primarily as memory
`devices. The main purpose of a session involving the card
`wastherefore to read data to or write data from a selected
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`20
`
`20
`
`

`

`US 7,232,073 B1
`
`7
`the smart card further
`In one particular embodiment,
`comprises a card managementapplication, which is respon-
`sive to a request to make an application the default appli-
`cation. The request may be made whenthe application to be
`made default application is being installed onto the smart
`card. In one embodiment, the card managementapplication
`verifies that the application requested to becomethe default
`application implements a predetermined interface. In one
`embodiment, the predeterminedinterface is defined to sup-
`port at least the first operation.
`Another embodiment of the invention provides a method
`of operating a smart card having multiple applications
`installed thereon. The method comprises designating one of
`the multiple applications as a default application. The
`default application is required to implementa first operation
`to provide a canonically ordered list of said multiple appli-
`cations on the card. The default application is activated
`wheneverthe cardis reset.
`Another embodiment of the invention provides a method
`of designating an application on a smart card as a default
`application. The method comprises receiving a request to
`designate an application as a default application on the smart
`card; confirming that the default application implements a
`first operation to provide a canonically ordered listing of
`multiple applications on the card; and designating the
`requested application as the default application, subject to a
`positive outcome from the confirming.
`Other embodiments of the invention provide data struc-