a2, United States Patent
`US 6,220,510 B1
`(10) Patent No.:
`*Apr. 24, 2001
`(45) Date of Patent:
`Everett et al.
`
`US006220510B1
`
`(54) MULTI-APPLICATION IC CARD WITH
`DELEGATION FEATURE
`
`(75)
`
`Inventors: David Barrington Everett, East
`Sussex; Stuart James Miller, Berks;
`Anthony David Peacham, Kent; Ian
`Stephen Simmons, Cambs; Timothy
`Philip Richards, Herts; John Charles
`Viner, Windlesham, all of (GB)
`
`4,321,672
`4,341,951
`4,405,829
`4,408,203
`4,423,287
`
`3/1982 Braun etal. .
`7/1982 Benton .
`9/1983 Rivest et al.
`10/1983 Campbell .
`12/1983 Zeidler.
`(List continued on next page.)
`
`.
`
`FOREIGN PATENT DOCUMENTS
`0152024
`8/1985 (EP) .
`0157303
`10/1985 (EP).
`
`(73) Assignee: Mondex International Limited, 0190733—-8/1986. (EP).
`
`London (GB)
`0218176
`4/1987 (EP).
`0261030
`3/1988 (EP).
`t
`List
`continued
`(List continued on next page.)
`OTHER PUBLICATIONS
`.
`.
`“Security for Computer Networks: An Intro-
`Davies et al.,
`duction to Data Security in Teleprocessing and Electronic
`Funds Transfer,” John Wiley & Sons 1984.
`Primary Examiner—Mark Tremblay
`(74) Attorney, Agent, or Firm—Baker Botts L.L.P.
`67)
`ABSTRACT
`A multi-application IC card which processes two or more
`applications using an Application Abstract Machine archi-
`tecture. The AAM architecture only allows one application
`to be executed at a time and allowsfor shared processing by
`performing a delegation function to a second application. A
`data space for each application is allocated when the appli-
`cation 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 ofthe 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 modelallowsfor a high level of security
`while transferring data between applications.
`
`«
`
`(*) Notice:
`
`This patent issued on a continued pros-
`ecution application filed under 37 CFR
`1.53(d), and is subject to the twenty year
`patent
`term provisions of 35 U.S.C.
`154(a)(2).
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`US.C, 154(b) by 0 days.
`(21) Appl. No.: 09/064,915
`(22)
`Filed:
`Apr. 23, 1998
`
`(60)
`
`Related U.S. Application Data
`Provisional application No. 60/046,514, filed on May 15,
`1997, and provisional application No. 60/046,543,filed on
`May15, 1997.
`Tint, C07 oeeceecessssscsssssssssseseesnssseeusseeetnesee G06K 5/00
`(SL)
`(52) U.S. Che cessnecsesntsenene 235/380; 235/379; 705/41
`(58) Field of Search
`,
`2351379 380
`ee335/492: 705’41
`,
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`wi080 ee al
`3/1981 Campbell . -
`11/1981 Bouricius et al.
`12/1981 Benton .
`
`.
`
`toteeao
`4.959.720
`4,302,810
`4,305,059
`
`63 Claims, 7 Drawing Sheets
`
`SAMSUNG 1007
`
`
`
`
`
`
`
`
`‘etselest_file_eppicationid
`te
`‘etepate_applcation_id
`
` 1
`
`
`
`SAMSUNG 1007
`
`1
`
`

`

`US 6,220,510 B1
`
`Page 2
`
`
`
`.
`
`.
`
`.
`
`.
`
`U.S. PATENT DOCUMENTS
`.
`aii084 Wolteret al.
`.
`.
`8/1984 Mollier .
`2/1985 Decaveleetal. .
`8/1985 Atalla et al.
`.
`3/1986 Zeidler.
`8/1986 Campbell, Jr.
`12/1986 Hallberg .
`12/1986 White .
`3/1987 Hudson etal. .
`6/1987 Capers etal. .
`11/1987 Hondaetal. .
`11/1987 Watanabe .
`11/1987 Yoshida .
`2/1988 Savar.
`2/1988 Nakanoetal. .
`3/1988 Smith .
`3/1988 Watanabe.
`4/1988 Yoshida.
`5/1988 Daughterset al.
`5/1988 Davis et al.
`.
`5/1988 Kawana .
`5/1988 Tamadaetal. .
`5/1988 Shamiretal. .
`6/1988 Nakanoetal. .
`7/1988 Onishi .
`7/1988 Tamadaetal. .
`7/1988 Chaum .
`7/1988 Chaum .
`8/1988 Kitta et al.
`10/1988 Ushikubo .
`11/1988 Kushima .
`11/1988 Kruseet al.
`1/1989 Hara .
`1/1989 Stein .
`1/1989 Watanabe .
`.
`1/1989 Wright et al.
`2/1989 Sugaharaet al.
`3/1989 Hazard .
`3/1989 Anderetal. .
`3/1989 Anderlet al.
`.
`4/1989 Chemin etal. .
`5/1989 Ogasawara .
`5/1989 lijima .
`6/1989 Dethloff et al. oe 235/380
`6/1989 Nakano .
`6/1989 lijima .
`7/1989 Watanabeet al.
`8/1989 Ogasawara .
`8/1989 Pastor .
`10/1989 Younger.
`10/1989 Fujisaki .
`10/1989 Mori.
`11/1989 Leighton etal. .
`11/1989 Anderl etal. .
`12/1989 Iijima .
`1/1990 Jewell .
`1/1990 ‘Yoshimatsu .
`2/1990 Wright et al.
`2/1990 lijima .
`3/1990 Halpern .
`3/1990 Hazard .
`5/1990 Chaum .
`6/1990 Austin .
`8/1990) Orbach wo. eee teeeeceeeeneee 364/401
`10/1990 Elliott et al.
`.
`11/1990 Schébi.
`12/1990 Ohtaet al.
`1/1991 LaBounty .
`1/1991 Tijima .
`
`texan,
`isa
`4,467,139
`4,498,000
`4,536,647
`4,578,530
`4,605,820
`4,629,872
`4,630,201
`4,650,978
`4,669,596
`4,705,211
`4,709,136
`4,709,137
`4,727,243
`4,727,244
`4,731,842
`4,734,568
`4,736,094
`4,742,215
`4,745,267
`4,746,788
`4,748,557
`4,748,668
`4,752,677
`4,757,185
`4,757,543
`4,759,063
`4,759,064
`4,767,920
`4,778,983
`4,785,166
`4,786,790
`4,797,542
`4,797,920
`4,798,941
`4,802,218
`4,803,347
`4,811,393
`4,816,653
`4,816,654
`4,825,052
`4,831,245
`4,833,595
`4,837,422 *
`4,839,504
`4,839,792
`4,849,614
`4,853,522
`4,853,961
`4,874,935
`4,877,945
`4,877,947
`4,879,747
`4,882,474
`4,887,234
`4,891,503
`4,891,506
`4,900,904
`4,901,276
`4,906,828
`4,907,270
`4,926,480
`4,935,962
`4,949,257
`4,961,142
`4,969,188
`4,977,595
`4,984,270
`4,985,615
`
`.
`
`.
`
`.
`
`.
`
`4,987,593
`4,993,068
`4,995,081
`4,996,711
`oscoa
`a
`5,005,200
`5,010,239
`5,012,074
`5,012,076
`5,014,312
`5,016,274
`5,038,025
`5,068,894
`5,093,862
`5,097,115
`5,120,939
`5,128,997
`5,131,038
`5,142,578
`5,146,499
`5,148,481
`5,161,231
`5,162,989
`5,163,098
`5,164,988
`5,165,043
`5,166,503
`5,175,416
`5,180,901
`5,191,193
`5,191,608
`5,200,999
`5,201,000
`5,202,922
`5,214,702
`5,224,162
`5,243,175
`5,247,578
`5,293,577
`5,371,797
`5,420,405
`5,452,431
`5,473,690
`5,485,520
`5,511,121
`5,517,011
`5,530,232
`5,534,857
`5,539,825
`5,542,081
`5,544,246
`5,546,523
`5,557,516
`5,557,742
`5,574,269
`5,578,808
`5,581,708
`5,588,146
`5,600,818
`5,649,118
`5,682,027
`5,692,132
`5,699,528
`5,704,046
`5,705,798
`5,708,780
`5,715,314
`5,724,424
`5,729,717
`5,796,831
`
`1/1991 Chaum .
`2/1991 Piosenkaetal. .
`2/1991 Leightonetal. .
`2/1991 Chaum .
`:
`1001 oe ‘tal
`Tinagawa
`4/1991 Fischer .
`4/1991 Mita .
`4/1991 Masada .
`4/1991 Yoshida .
`5/1991 Lisimaqueetal. .
`5/1991 Micali et al.
`.
`8/1991 Kodera .
`11/1991 Hoppe .
`3/1992 Sewartz .
`3/1992 Ogasawaraet al.
`6/1992 Clauset al.
`.
`7/1992 Pailles et al.
`7/1992 Puhletal. .
`8/1992 Matyaset al.
`9/1992 Geffrotin .
`9/1992 Abraham etal. .
`11/1992 Iijima .
`11/1992 Matsuda 0... eee ceceeeee 364/401
`11/1992 Dahbura .
`11/1992 Matyas etal. .
`11/1992 Miyaharaetal. .
`11/1992 Mizuta .
`12/1992 Mansveltet al.
`1/1993 Hiramatsu .
`3/1993 Le Roux .
`3/1993 Geronimi.
`.
`4/1993 Matyaset al.
`4/1993 Matyasetal. .
`4/1993 lijima .
`5/1993 Fischer .
`6/1993 Okamotoetal. .
`9/1993 Kato.
`9/1993 Pailles et al.
`3/1994 Hueskeet al.
`12/1994 Bocinsky, Jr.
`5/1995 Chasek .
`9/1995 Bournas .
`12/1995 Grimonprezetal. .
`1/1996 Chaum etal. .
`4/1996 Yacobi.
`5/1996 Vandenengel .
`6/1996 Taylor .
`.
`7/1996 Laing et al.
`7/1996 Akiyamaetal. .
`7/1996 Geronimi.
`8/1996 Mandelbaumetal. .
`8/1996 Gatto .
`9/1996 Hogan .
`9/1996 Smahaet al. wees 395/186
`11/1996 Moriet al.
`.
`11/1996 Taylor .
`12/1996 lijima .
`12/1996 Leroux .
`2/1997 Weikmann ou... ee eeeeeeeeeee 711/163
`7/1997 Carlisle et ab. oes 705/41
`10/1997 Bertinaet al.
`.
`11/1997 Hogan .
`12/1997 Hogan .
`12/1997 Hogan.
`1/1998 Tarbox .
`1/1998 Levergoodet al.
`2/1998 Payneetal. .
`3/1998 Gifford .
`3/1998 Tamadaet al. oes 711/164
`8/1998 Paradinaset al.
`.
`
`-
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`2
`
`

`

`US 6,220,510 B1
` Page 3
`
`5,802,519 *
`5,825,875
`
`cresesssssssssessssesesesmnsssees 707/100
`9/1998 Jong.
`10/1998 Ugon .
`
`FOREIGN PATENT DOCUMENTS
`0275510
`7/1988 (EP).
`0292248
`11/1988 (EP).
`0325506
`1/1980 (EP).
`0328289
`8/1989 (EP).
`0354793
`2/1990 (EP).
`0451936
`10/1991 (EP).
`0466969
`‘1/1992 (EP).
`0475837
`3/1992 (EP).
`0547741
`9/1992 (EP).
`0537756
`4/1993 (EP).
`0540095
`5/1993 (EP).
`0559205
`8/1993 (EP).
`0588339
`3/1994 (EP).
`0594493
`4/1994 (EP).
`0686947
`of 1995 (EP) .
`0636998
`2/1995 (EP).
`0647902
`4/1995 (EP).
`0666550
`8/1995 (EP).
`0707290
`9/1995 (EP).
`
`0751460
`2536928
`2667171
`
`1/1997 (EP) .
`6/1984 (FR).
`of 1992
`(FR).
`
`3/1993 FR)
`2687816
`6/1995 (GB)
`2284689
`3/1989 (JP) .
`6481084
`12/1996 (JP).
`2592856
`11/1987 (WO)
`8707062
`11/1988 (WO)
`8809019
`5/1990 (WO)
`WO 9005960
`10/1991 (WO)
`WO 9116691
`8/1992 (WO)
`9213322
`10/1993 (WO)
`WO 9320538
`10/1993 (WO)
`WO 9321612
`8/1995 (WO)
`WO 9522810
`6/1996 (WO)
`9619771
`9/1996 (WO)
`9628795
`12/1996 (WO)
`9638825
`10/1998 (WO)
`9843212
`2/1999 (WO)
`WO 9101538
`3/1999 (WO)
`9910824
`4/1999 (WO)
`9916031
`* cited by examiner
`
`3
`
`

`

`U.S. Patent
`
`Apr. 24, 2001
`
`Sheet 1 of 7
`
`US 6,220,510 B1
`
`121
`
`119
`
`117
`
`111
`
`109
`
`
`415oR
`
`YHA
`
`
`YD
`
`
`
`107
`
`105
`
`103
`
`STATIC
`
`FIGURE1
`
`4
`
`

`

`U.S. Patent
`
`Apr. 24, 2001
`
`Sheet 2 of 7
`
`US 6,220,510 B1
`
`y 207
`
`205
`
`CCR
`
`209
`
`201
`
`203
`
`FIGURE 2
`
`5
`
`

`

`U.S. Patent
`
`Apr. 24, 2001
`
`Sheet 3 of 7
`
`set delegator application _ id to selected _ file. application _ id
`
`301
`
`push delegator_ application _ id on to delegate _id_ stack
`
`303
`
`send application command to AAM operating system US 6,220,510 B1
`
`set selected _ file_ application _ id to delegate _ request.delegate
`_ application id
`
`
`
`set application _ command to delegate _ request.application _
`command parameter
`
`305
`
`307
`
`309
`
`FIGURE 3
`
`6
`
`

`

`U.S. Patent
`
`Apr. 24, 2001
`
`Sheet 4 of 7
`
`US 6,220,510 B1
`
`get application_responses from delegatee
`
`set delegate_response_status to "success"
`
`application_responses
`
`set delegate_response_application_responses
`to
`
`set delegate_response_delegate_application_id
`to
`
`selected_file_application_id
`data stock
`delegate_application_id
`
`pop delegate_application_id
`from
`
`set select_file_application_id
`to
`
`401
`
`403
`
`405
`
`407
`
`409
`
`411
`
`to current application
`
`send
`delegate_response_data
`
`413
`
`FIGURE 4
`
`7
`
`

`

`U.S. Patent
`
`Apr.24, 2001
`
`Sheet 5 of 7
`
`US 6,220,510 B1
`
`Receive Delegate
`id request
`
`901
`
` Is ID stack empty?
`
`set status to failure
`
`511
`
`513
`
`
`
`
`
`
`
`505
`
`507
`
`509
`
`
`set status to “success”
`set responseto "no
`delegator application”
`
`
`retrieve data from
`stack and set response
`to delegatorid
`
`Send responseto
`operating system
`
`FIGURE 5
`
`8
`
`

`

`U.S. Patent
`
`617
`
`0)(9)
`
`US 6,220,510 B1
`
`601
`
`611
`
`609
`
`607
`
`FIGURE 6
`
`605
`
`603
`
`615
`
`Apr.24, 2001
`
`Sheet 6 of 7
`
`Control Logic
`
`vO
`
`613
`
`o
`
`9
`
`

`

`U.S. Patent
`
`Apr.24, 2001
`
`Sheet 7 of 7
`
`US 6,220,510 B1
`
`~ ° —_
`
`DELEGATEVi —
`
`703
`
`FIGURE 7A
`
`():
`
`711
`| DELEGATE |
`oo
`
`703
`
`701
`
`OY 708
`
`"
`
`705
`
`709
`
`713
`707
`
`
`
`FIGURE 7B
`
`708
`
`FIGURE 7C
`
`10
`
`10
`
`

`

`US 6,220,510 B1
`
`1
`MULTI-APPLICATION IC CARD WITH
`DELEGATION FEATURE
`
`PRIORITY APPLICATIONS
`
`This application claimspriority to U.S. Provisional appli-
`cation 60/046,514 filed on May 15, 1997, entitled “Design
`for a Multi Application Smart Card” and U.S. Provisional
`application 60/046,543 filed on May 15, 1997, entitled
`“Virtual Machine for a Multi Application Smart Card”.
`BACKGROUND OF INVENTION
`
`Integrated circuit (“IC”) cards are becoming increasingly
`used for many different purposes in the world today. An IC
`card (also called 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 appli-
`cation operating system which runs on IC cards, among
`other platforms, and allows multiple applications to be
`executed on the card itself. The multiple application oper-
`ating system present on the IC card allows a card user to run
`many programsstored in the card (for example, credit/debit,
`electronic money/purse and/or loyalty applications) irre-
`spective 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 applica-
`tion wheninserted into a terminal. For example, a telephone
`card could only be used to charge a telephonecall 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 user
`would be required to carry multiple physical cards on his or
`her person, which would be quite cumbersome and incon-
`venient. 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 outof the card-receiving terminal
`during the transaction, making 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 infor-
`mation (including application code and associated data)
`exchanged between the individual card and the application
`provider as well as within the entire system when commu-
`nicating information between applications.
`For instance, the existence of multiple applications on the
`same card allows for the exchange of data between two
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`2
`applications, while one of the applicationsis 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 between applications in an
`insecure manner, it may be possible for a third party moni-
`toring the transaction to determine the contents of the
`transferred 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 organi-
`zation which protects an application’s data from being
`discovered by a third party 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 organization which
`provides for a secure data interaction between applications
`and allows multiple applications to be accessed while per-
`forming a desired task or function.
`SUMMARYOF THE INVENTION
`
`The present invention provides for a multiple application
`architecture for an IC card called an application abstract
`machine (AAM)and a method for implementing that archi-
`tecture. The processing of multiple applications is accom-
`plished by generating for at least one application (the “first
`application”) a data memory space including at least two
`segments, a volatile memory segment and a non-volatile
`memory segment, commencing the execution of the first
`application’s instructions; delegating or switching execution
`from thefirst application to the delegated application and in
`so doing, saving any data generated by thefirst application
`in the logical data memory space associated with the first
`application; executing the second application’s instructions;
`retrieving the 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
`commanddelegatedis interpreted by a delegated application
`in the same manneras a selection command being issued
`directly by a terminal and therefore each application per-
`formsthe security functions at the samelevel as if a terminal
`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 whenstored 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 descrip-
`tion 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 organization;
`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 perform-
`ing a request for a delegation fuinction by one application to
`another;
`FIG. 4 is a flow diagram illustrating the steps of perform-
`ing a return delegation control function for a delegate
`application to a delegator application;
`11
`
`11
`
`

`

`US 6,220,510 B1
`
`3
`FIG. 5 is a flow diagram illustrating the steps of perform-
`ing 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
`FIGS. 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, componentsorportionsof the illustrated
`embodiments. Moreover, while the subject invention will
`now bedescribed 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.
`DETAILED DESCRIPTION OF THE
`INVENTION
`
`The present invention provides for a method and appa-
`ratus 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 terminal, or other interface device, or another
`application. Each application program whichisstored on the
`IC card when executed is allocated a memory space orga-
`nized 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 spe-
`cific loyalty application such as a frequent flyer awards
`application. Each application has software code and associ-
`ated 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 elec-
`tronically spent to make a purchase, the user may beentitled
`to one frequent flyer mile which is stored and processed by
`the frequent flyer program. 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 program 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 frequentflyer miles for the user of the
`card.
`
`When two applications need to communicate during the
`sametransaction, a system architecture is required to process
`both applications in an efficient and secure manner. One
`approach could be a windows type model where both
`applications could be running at the same time. Presently,
`however, IC card platforms are not powerful enough to
`simultaneously operate multiple programsefficiently. Also,
`transferred data may be exposed to unwanted third party
`access. The solution to this problem, provided by the current
`invention, which is described in greater detail below, is to
`selectively interrupt the execution of applications in a secure
`manner. This allowsthe integrity of the applications’ data to
`be maintained and allowsthe best utilization of 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
`
`10
`
`15
`
`20
`
`25
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`hardware and enables developers to write applications to
`store on the IC cards which are portable across many
`different types of platforms(e.g., IC cards built by different
`manufacturers with different processor configurations) with-
`out the need for knowledge about the specific hardware of
`the platform.
`An application abstract machine (AAM), a term 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 transferred 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 whichis virtually allocated and mapped onto
`the physical memory addresses available in the IC card
`memories. Data is then passed between two or more appli-
`cations 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 spacecreated for each application
`being executed includes two separate address spaces, one for
`the program codeitself 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 FIG.
`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 reg-
`isters and two control registers.
`FIG. 1 showsan illustrative diagram of a logical data
`space allocation 101 created for an application used in
`conjunction with the present
`invention. The AAM data
`portion 101 includes a Static data space 103, a Public data
`space 105 and a Dynamic data space 107. Also shownare 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 frame pointer in the Dynamic data space
`when the application is being executed. The address regis-
`ters 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 memorysize.
`The registers can also be considered pointers or can be any
`other conventional addressing mechanism.
`the Static
`Within the allocated AAM data space 101,
`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 terminalafter it is interfaced
`into the terminal. Although an IC card may contain a battery
`to maintain some power for memory andcircuitry, 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 that applications can perform
`pointer and offset arithmetic. For example, if the segment
`addresses “1515” and “1516,” or any other pair of sequential
`12
`
`12
`
`

`

`US 6,220,510 B1
`
`5
`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 first
`byte of the Static segment
`is zero, so that the segment
`address of a given location within the Static region is equal
`to its offset.
`
`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 nameis 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 5” byte above the Static Bottom. Since the
`Static memoryis 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.
`Onthe 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 seg-
`ment 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 appli-
`cation. The address of a memory location of Dynamic or
`Public segmentis 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 seg-
`ment 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 the AAM data
`space contain a segment physical address. For instance, the
`address 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.
`the allocated Static segment 103
`Referring to FIG. 1,
`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 segmentat 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 STis equal to
`the size of the application’s Static data which is set when the
`
`10
`
`15
`
`20
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`application is loaded onto the IC card. The multiple appli-
`cation operating system ensuresthat 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 appli-
`cation 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 amountof 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 twoparts, 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
`framepointer to particular memorylocations 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 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.
`the Dynamic
`When an application is being executed,
`segment created for that application also contains the appli-
`cation’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 commandinstead of pro-
`cessing the command itself. An example of a delegation
`function occurs when a delegator application receives a
`commandthatit does not recognizeoris 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 primi-
`tive. The Delegate primitive is a subroutine recognized by
`the multiple application operating system which is executed
`when the operating system interprets the Delegate instruc-
`tion. Primitives can bestored 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
`13
`
`13
`
`

`

`US 6,220,510 B1
`
`7
`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 sentto the
`Public memoryspace of the second application (which could
`be physically the same memory butis allocated separat