United States Patent [19J
`Chan et al.
`
`[54] SYSTEM AND METHOD FOR A MULTI(cid:173)
`APPLICATION SMART CARD WHICH CAN
`FACILITATE A POST-ISSUANCE
`DOWNLOAD OF AN APPLICATION ONTO
`THE SMART CARD
`
`[75]
`
`Inventors: Alfred Chan, Daly City; Marc B.
`Kekicheff, Palo Alto; Joel M. Weise,
`Burlingame; David C. Wentker, San
`Francisco, all of Calif.
`
`[73] Assignee: Visa International Service
`Association, Foster City, Calif.
`
`[21] Appl. No.: 09/046,993
`
`[22] Filed:
`
`Mar. 24, 1998
`
`[60]
`
`[51]
`
`[52]
`
`[58]
`
`[56]
`
`Related U.S. Application Data
`Provisional application No. 60/061,763, Oct. 14, 1997, and
`provisional application No. 60/041,468, Mar. 24, 1997.
`Int. Cl.6
`................................ H04L 9/00; H04L 9/08;
`G07F 7/08
`U.S. Cl. ................................... 380/25; 380/9; 380/21;
`380/23; 380/24; 380/29; 380/30; 380/49;
`380/50; 235/379; 235/380
`Field of Search .................................... 380/4, 23, 24,
`380/25, 49, 50, 59, 9, 21, 29, 30; 235/379,
`380, 382; 379/93.01, 93.05, 93.06, 93.12
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`4,742,215
`5,332,889
`5,378,884
`5,530,232
`5,583,933
`
`..................... 235/487
`5/1988 Daughters et al.
`7/1994 Lundstrom et al. .................... 235/380
`1/1995 Lundstrom et al. ................ 235/380 X
`6/1996 Taylor ..................................... 235/380
`12/1996 Mark ....................................... 380/9 X
`
`FOREIGN PATENT DOCUMENTS
`
`E 100227 11/1994 Austria .
`0193635 Al
`9/1986 European Pat. Off ..
`19607363 Al
`9/1996 Germany .
`
`OTHER PUBLICATIONS
`
`EPO, International Search Report, Jul. 3, 1998, International
`Application No. PCT/US 98/05674.
`Carol Hovenga Fancher,"In Your Pocket Smart Cards", Feb.
`1997, IEEE.
`Chaum et al., "Smart Card 2000: The Future of IC Cards",
`Oct. 19, 1987, Elsevier Science Publishers B.V.
`Steven Levy, "E-Money (That's What I Want)", Dec. 1994,
`Wired Magazine.
`Carol H. Fancher, "Smart Cards as Potential Applications
`Grow, Computers in the Wallet are Making Unobtrusive
`Inroads", Aug. 1996, Scientific American Website.
`Jerome Svigals, "Smart Cards The New Bank Cards", 1985,
`MacMillan Publishing Company.
`Roy Bright, "Smart Cards: Principles, Practice, Applica(cid:173)
`tions", 1988, Ellis Horwood Limited.
`Jerome Svigals, "Smart Cards The Ultimate Personal Com(cid:173)
`puter", 1985, MacMillan Publishing Company.
`Hawkes et al., "Integrated Circuit Cards, Tags and Tokens",
`1990, ESP Professional Books.
`
`I 1111111111111111 11111 1111111111 11111 111111111111111 lllll 111111111111111111
`US006005942A
`[11] Patent Number:
`[45] Date of Patent:
`
`6,005,942
`Dec. 21, 1999
`
`Hirn Shogase, "The Very Smart Card: A Plastic Packet
`Bank", Oct. 1988, IEEE Spectrum.
`David Naccache, "Cryptographic Smart Cards", Jun. 3,
`1996, IEEE Micro 1996 Website.
`Zoreda et al., "Smart Cards", 1994, Artech House.
`"Identification Card Systems-Inter-Sector Electronic
`Purse Part 1: Concepts and Structures", 1994, European
`Standard, prEN 1546.
`"Identification Card Systems-Inter-Sector Electronic
`Purse Part 2: Security Architecture", 1994, European Stan(cid:173)
`dard, prEN XXXXX-2.
`"Identification Card Systems-Inter-Sector Electronic
`Purse Part 3: Data Elements and Interchanges", 1994, Euro(cid:173)
`pean Prestandard, prEN 1546-3.
`"Identification Card Systems-Inter-Sector Electronic
`Purse Part 4: Devices", 1994, European Prestandard, prEN
`1546-4.
`"Identification Cards-Integrated Circuit(s) Cards With
`Contacts Part 1: Physical Characteristics", 1987, Interna(cid:173)
`tional Standard, ISO 7816-1, First Edition.
`"Identification Cards-Integrated Circuit(s) Cards With
`Contacts Part 2: Dimensions and Location of the Contacts",
`1988, International Standard, ISO 7816-2, First Edition.
`"Identification Cards-Integrated Circuit(s) Cards With
`Contacts Part 3: Electronic Signals and Transmission Pro(cid:173)
`tocols", International Standard, ISO/IEC 7816-3, First Edi(cid:173)
`tion.
`"Identification Cards-Integrated Circuit(s) Cards With
`Contacts Part 4: Inter-Industry Commands for Interchange",
`International Standard, ISO/IEC 7816-4, First Edition.
`"Identification Cards-Integrated Circuit(s) Cards With
`Contacts Part 5: Numbering System and Registration Pro(cid:173)
`cedure for Application Identifiers", 1993, International Stan(cid:173)
`dard, ISO/IEC DIS 7816-5.
`"Identification Cards-Physical Characteristics", 1995,
`International Standard, ISO/IEC 7810, Second Edition.
`"Identification Cards-Recording Technique-Part
`1:
`Embossing", 1995,
`International Standard,
`ISO/IEC
`7811-1, Second Edition.
`
`(List continued on next page.)
`
`Primary Examiner-Bernarr E. Gregory
`Attorney, Agent, or Firm-Beyer & Weaver, LLP
`
`[57]
`
`ABSTRACT
`
`A system and method allow card issuers to securely add
`applications during the lifetime of the card after the card has
`already been issued (post issuance). Loading of an applica(cid:173)
`tion and/or objects from an application server via a card
`acceptance device (and its supporting system infrastructure
`delivery mechanism) onto a card post issuance is performed
`in a secure and confidential manner. A smart card includes
`a card domain application that manages the card. Any
`number of security domain applications on the card provide
`security for loaded applications by managing keys; each
`application is associated with a security domain. Each of the
`card domain and security domains has a command interface
`for off-card communication, and an API for internal card
`use. The card life cycle includes the states of masked,
`initialized, load secured and blocked. An application life
`cycle includes the states of not available, loaded, installed,
`registered, personalized, activated and blocked. An applica(cid:173)
`tion can block the card.
`
`24 Claims, 15 Drawing Sheets
`
`GOOG-1008
`GOOGLE LLC v. RFCYBER CORP. / Page 1 of 34
`
`

`

`6,005,942
`Page 2
`
`OIBER PUBLICATIONS
`
`"Identification Cards-Recording Technique-Part 2: Mag(cid:173)
`netic Stripe", 1995, International Standard, ISO/IEC
`7811-2, Second Edition.
`"Identification Cards-Recording Technique-Part 3: Loca(cid:173)
`tion of Embossed Characters on ID-1 Cards", 1995, Inter(cid:173)
`national Standard, ISO/IEC 7811-4, Second Edition.
`"Identification Cards-Recording Technique-Part 5: Loca(cid:173)
`tion of Read-Write Magnetic Track-Track 3", 1995, Inter(cid:173)
`national Standard, ISO/IEC 7811-5, Second Edition.
`"Identification Cards-Recording Technique-Part 6: Mag(cid:173)
`netic Stripe-High Coercivity", 1996, International Standard,
`ISO/IEC 7811-6, First Edition.
`
`"Identification Cards-Financial Transaction Cards", 1990,
`International Standard, ISO/IEC 7813, Fourth Edition.
`
`"Identification Cards-Financial Transaction Cards Amend(cid:173)
`ment 1", 1996, International Standard, ISO/IEC 7813,
`Fourth Edition.
`
`Integrated Circuit(s)
`"Identification Cards-Countless
`Cards-Part 1: Physical Characteristics", 1992, Interna(cid:173)
`tional Standard, ISO/IEC 10536-1, First Edition.
`
`"Identification Cards-Contactless Integrated Circuit(s)
`Cards-Part 2: Dimensions and Location of Coupling
`Areas", 1995, International Standard, ISO/IEC 10536-2,
`First Edition.
`
`GOOG-1008
`GOOGLE LLC v. RFCYBER CORP. / Page 2 of 34
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 1 of 15
`
`6,005,942
`
`(
`r
`
`0
`T""
`
`LO
`
`v-
`
`~ ~
`
`~
`
`0 c:::
`
`~~
`
`~
`
`c2
`
`~~
`w
`c::: u
`ow<C
`0::: 0 LL
`<( <( c:::
`uww
`c::: I-z -
`
`N
`N
`
`co
`
`T""
`
`N
`T""
`
`u
`I
`a.. w
`<( ....J
`c::: ::J
`(9 0 Oo
`t~
`>-c:::
`u
`
`W>-
`I =:! c:::
`ZI-Q
`o::5~
`z 0 w
`>~
`
`c:::
`0
`Cf)
`Cf) w
`u
`0 c:::
`a..
`0 c:::
`u
`~
`
`0
`0::::
`<(
`l)
`l(cid:173)
`o::::
`<(
`:2:
`Cl)
`
`-l-a::
`
`T""" <(
`. a::
`(9 0
`LL -a::
`
`a. -
`
`GOOG-1008
`GOOGLE LLC v. RFCYBER CORP. / Page 3 of 34
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 2 of 15
`
`6,005,942
`
`206A
`
`APPLET 1
`
`APPLET 2
`
`CARD APPLICATION PROGRAMMING
`INTERFACE
`(CARD API)
`
`OPERATING SYSTEM
`
`200
`
`SMART CARD SOFTWARE LAYERS
`
`FIG. 2
`(PRIOR ART)
`
`GOOG-1008
`GOOGLE LLC v. RFCYBER CORP. / Page 4 of 34
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 3 of 15
`
`6,005,942
`
`308
`~
`
`CARD DOMAIN
`
`COMMAND
`INTERFACE
`
`DOMAINAPI
`
`,,,,,.--352
`V
`
`/
`
`,,,,,.-- 350
`--
`
`APPLET
`
`APPLET
`
`APPLET
`
`I COMMAND I
`INTERFACE
`I
`
`I COMMAND I
`INTERFACE
`I
`
`I COMMAND I
`INTERFACE
`
`(
`
`306
`
`,, J
`OPEN
`PLATFORM -
`API
`(OP API)
`
`~354A
`305A
`
`~3548
`305B
`
`54C
`\ 3
`
`30 5C
`
`_____.
`
`'
`''
`"
`CARD APPLICATION PROGRAMMING INTERFACE
`(CARD API)
`
`\__304
`
`"
`
`-
`
`OPERATING SYSTEM
`
`~ 300
`
`FIG. 3A
`
`GOOG-1008
`GOOGLE LLC v. RFCYBER CORP. / Page 5 of 34
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 4 of 15
`
`6,005,942
`
`310A
`~
`
`~ 3108
`
`SECURITY DOMAIN 1
`
`SECURITY DOM AIN 2
`
`c::;: 320A
`
`COMMAND
`INTERFACE
`c::;: 322A
`
`SECURITY API
`
`208
`c::;:3
`
`COMMAND
`INTERFACE
`s
`3228
`SECURITY A
`Pl
`
`I
`
`I
`
`~308'
`
`CARD DOMAIN
`
`c::;:352'
`COMMAND
`INTERFACE
`s
`350'
`DOMAIN API
`
`I
`
`I
`
`-
`-
`
`--
`
`APPLET
`
`APPLET
`
`APPLET
`
`I COMMAND I
`INTERFACE
`I
`
`I COMMAND I
`INTERFACE
`I
`
`r COMMAND1
`
`INTERFACE
`I
`
`~354A'
`305A'
`
`~354B'
`3058'
`
`4C'
`~35
`
`30 5C'
`
`'
`CARD APPLICATION PROGRAMMING INTERFACE
`(CARD API)
`
`1.
`
`Ir
`
`306'
`1' J
`OPEN
`PLATFORM >--
`API
`(OP API)
`
`L...+
`
`"--304'
`
`1
`
`OPERATING SYSTEM
`
`"-- 300 I
`
`FIG. 3B
`
`GOOG-1008
`GOOGLE LLC v. RFCYBER CORP. / Page 6 of 34
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 5 of 15
`
`6,005,942
`
`ISSUE A SMART
`CARD
`
`400
`
`402
`
`404
`
`FORWARD AN APPLICATION TO
`THE ISSUED SMART CARD
`
`LOAD THE APPLICATION ONTO THE
`SMART CARD USING THE CARD
`DOMAIN
`
`FIG. 4
`
`CREATE A SMART CARD AND PROVIDE A
`FIRST APPLICATION TO THE SMART
`CARD THAT INCLUDES A
`CRYPTOGRAPHIC SERVICE
`
`1002
`~
`
`•Ir
`
`LOAD A SECOND APPLICATION
`ONTO THE SMART CARD
`
`1004
`v---../
`
`,,
`INSTALL THE SECOND APPLICATION
`USING THE CRYPTOGRAPHIC
`SERVICE OF THE FIRST APPLICATION
`
`1006
`v---../
`
`FIG. 5
`
`GOOG-1008
`GOOGLE LLC v. RFCYBER CORP. / Page 7 of 34
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 6 of 15
`
`6,005,942
`
`ISSUER DEPLOYS SMART
`CARDS TO CUSTOMERS
`
`A DECISION IS MADE TO INSTALL A
`VENDOR APPLICATION ONTO A CARD
`
`500
`
`502
`
`WHEN A DIALOG BETWEEN THE ISSUER AND THE
`CARD IS INITIATED, A PRE-SIGNED COPY OF THE
`APPLICATION IS FORWARDED TO THE CARD
`
`CARD DOMAIN DECRYPTS THE APPLICATION
`AND CHECKS SIGNATURE OF APPLICATION
`
`504
`
`508
`
`520
`
`END
`
`512
`
`513
`
`518
`
`APPLICATION RECEIVES
`PERSONALIZATION DATA
`
`APPLICATION INVOKES CARD
`DOMAIN DECRYPTION SERVICE
`
`CARD DOMAIN PERFORMS A
`SIGNATURE CHECK
`
`ACTIVATE THE APPLICATION
`
`FIG. 6
`
`GOOG-1008
`GOOGLE LLC v. RFCYBER CORP. / Page 8 of 34
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 7 of 15
`
`6,005,942
`
`MASKED
`
`INITIALIZED
`
`LOAD SECURED
`
`BLOCKED
`
`700
`
`702
`
`704
`
`706
`
`FIG. 7A
`
`FIG. 78
`
`..
`
`NOT AVAILABLE
`
`Load
`
`LOADED
`
`Install
`
`INSTALLED
`
`Register
`
`REGISTERED
`
`750
`
`752
`
`754
`
`756
`
`758
`
`Block
`
`unblock
`
`BLOCKED
`
`760
`
`delete
`applet
`
`delete
`applet
`
`delete
`applet
`
`GOOG-1008
`GOOGLE LLC v. RFCYBER CORP. / Page 9 of 34
`
`

`

`"'-' N
`\0
`....
`.... = = Ul
`
`0--,
`
`'"""' Ul
`0 ....,
`00
`~ ....
`'JJ. =(cid:173)~
`
`\0
`\0
`'"""'
`\0
`'"""' ~
`N
`ri
`~
`~
`
`~ = ......
`~ ......
`~
`•
`r:JJ.
`d •
`
`802
`
`812
`
`810
`
`800
`
`FIG. 8
`
`Card blocked/ expired
`
`App. F life
`
`End of
`
`of card life
`
`used until end
`loaded, not
`
`post issuance
`
`EEPROM,
`
`Fis in
`
`Application
`
`Secure Install
`
`of life of card
`used until end
`secure install,
`loaded with
`post issuance
`
`EEPROM,
`
`Eis in
`
`Application
`
`of card
`
`complete life
`
`used for
`
`initialization,
`loaded during
`
`EEPROM,
`
`Dis in
`
`Application
`
`806
`
`App. C life
`
`End of
`
`of card
`
`complete life
`used not for
`initialization,
`loaded during
`
`EEPROM,
`
`C is in
`
`Application
`
`Secure Install
`
`Masked ROM
`
`804
`
`life of the card
`complete
`during the
`and used
`A is in ROM
`Application
`
`line
`time
`Life
`Card
`
`life of the card
`first part of the
`
`during the
`and used
`Bis in ROM
`Application
`
`GOOG-1008
`GOOGLE LLC v. RFCYBER CORP. / Page 10 of 34
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 9 of 15
`
`6,005,942
`
`AN APPLICATION IS IN USE
`
`APPLICATION DETECTS A
`PROBLEM WHICH TRIGGERS
`A CARD BLOCK REQUEST
`
`APPLICATION SENDS A
`CARD BLOCK REQUEST
`TO CARD DOMAIN
`
`600
`
`602
`
`604
`
`606
`
`NO
`
`CARD DOMAIN DOES
`NOT BLOCK CARD
`
`608
`
`YES
`
`610
`CARD DOMAIN AUTHORIZED i.,-----.../
`THE CARD BLOCKING
`
`CARD DOMAIN BLOCKS
`CARD
`
`612
`
`FIG. 9
`
`GOOG-1008
`GOOGLE LLC v. RFCYBER CORP. / Page 11 of 34
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 10 of 15
`
`6,005,942
`
`308
`
`CARD DOMAIN
`
`SECURITY DOMAIN A
`
`310A
`
`SECURITY DOMAIN B
`
`310B
`
`305A
`
`305B
`
`MASKED
`APPLICATION
`
`POST ISSUANCE
`LOADED APPLICATION
`
`FIG. 10
`
`GOOG-1008
`GOOGLE LLC v. RFCYBER CORP. / Page 12 of 34
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 11 of 15
`
`6,005,942
`
`ISSUER DECIDES TO INCLUDE A
`SECURITY DOMAIN ON CARD
`
`ISSUER ASSIGNS A SECURITY
`DOMAIN TO VENDOR A
`
`1100
`
`1102
`
`VENDOR A (OR AN APPLICATION DEVELOPER ON
`BEHALF OF VENDOR A) GENERATES SECRET
`KEYS AND SENDS THE KEYS TO A CARD
`PERSONALIZATION AGENT IN A SECURE MANNER
`
`CARD PERSONALIZATION AGENT RECEIVES KEYS
`AND LOADS A SECURE DOMAIN KEY ASSOCIATED
`WITH A SPECIFIC SECURITY DOMAIN FOR EACH
`CARD
`
`CARD PERSONALIZATION AGENT
`RECEIVES CARDS AND COLLECTS OTHER
`DATA AND PLACES DATA ON CARD
`
`1104
`
`1106
`
`1108
`
`ISSUER DEPLOYS
`CARDS TO CUSTOMERS
`
`A DECISION IS MADE TO INSTALL
`VENDOR A's APPLICATION ON THE
`CARD
`
`1110
`
`1112
`
`WHEN A DIALOG BETWEEN THE ISSUER AND THE
`CARD IS INITIATED, A PRE-SIGNED COPY OF THE
`APPLICATION IS FORWARDED TO THE CARD
`
`1114
`
`FIG. 11A
`
`GOOG-1008
`GOOGLE LLC v. RFCYBER CORP. / Page 13 of 34
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 12 of 15
`
`6,005,942
`
`CARD DOMAIN INVOKES SECURITY DOMAIN'S
`CRYPTOGRAPHIC SERVICE TO DECRYPT THE
`APPLICATION AND CHECK SIGNATURE
`
`1118
`
`NO
`
`END
`
`YES
`
`APPLICATION RECEIVES
`PERSONALIZATION DATA
`
`1124
`
`APPLICATION INVOKES SECURITY
`DOMAIN'S DECRYPTION SERVICE
`AND SIGNATURE CHECK
`
`1126
`
`ACTIVATE THE
`APPLICATION
`
`1130
`
`FIG. 11 B
`
`GOOG-1008
`GOOGLE LLC v. RFCYBER CORP. / Page 14 of 34
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 13 of 15
`
`6,005,942
`
`ISSUER DECIDES TO INCLUDE A
`SECURITY DOMAIN ON CARD
`
`TRUSTED PARTY GENERATES SECRET KEYS
`AND SENDS THE KEYS TO A CARD
`PERSONALIZATION AGENT IN A SECURE
`MANNER
`
`CARD PERSONALIZATION AGENT RECEIVES
`KEYS AND LOADS A SECURE DOMAIN KEY
`ASSOCIATED WITH A SPECIFIC SECURITY
`DOMAIN FOR EACH CARD
`
`CARD PERSONALIZATION AGENT RECEIVES
`CARDS AND COLLECTS OTHER DATA AND
`PLACES DA TA ON CARD
`
`ISSUER DEPLOYS
`CARDS TO CUSTOMER
`
`1200
`
`1201
`
`1202
`
`1204
`
`1206
`
`A DECISION IS MADE TO INSTALL VENDOR A's
`APPLICATION ON THE CARD
`
`VENDOR A OBTAINS SECRET KEYS FOR THE
`SECURITY DOMAIN FROM THE TRUSTED
`PARTY
`
`VENDOR A SENDS THE ISSUER A PRE-SIGNED
`COPY OF THE APPLICATION
`
`1208
`
`1210
`
`1212
`
`FIG. 12A
`
`GOOG-1008
`GOOGLE LLC v. RFCYBER CORP. / Page 15 of 34
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 14 of 15
`
`6,005,942
`
`WHEN A DIALOG BETWEEN THE ISSUER AND THE
`CARD IS INITIATED, A PRE-SIGNED COPY OF THE
`APPLICATION IS FORWARDED TO THE CARD (THE
`APPLICATION CAN BE PRE-SIGNED WITH A KEY
`EQUIVALENT TO THAT WHICH ALREADY EXISTS ON
`THE CARD SO THAT EACH APPLICATION HAS A
`UNIQUE SIGNATURE THAT CAN BE VERIFIED BY
`THE CARD)
`
`1214
`
`CARD DOMAIN INVOKES SECURITY
`DOMAIN'S CRYPTOGRAPHIC SERVICE
`TO DECRYPT THE APPLICATION AND
`CHECK SIGNATURE
`
`1218
`
`IS
`SIGNATURE
`VALID?
`
`NO
`
`END
`
`APPLICATION RECEIVES
`PERSONALIZATION DA TA
`
`APPLICATION INVOKES SECURITY
`DOMAIN'S DECRYPTION SERVICE
`AND SIGNATURE CHECK
`
`ACTIVATE THE APPLICATION
`
`1224
`
`1226
`
`1230
`
`FIG. 128
`
`GOOG-1008
`GOOGLE LLC v. RFCYBER CORP. / Page 16 of 34
`
`

`

`U.S. Patent
`
`Dec. 21, 1999
`
`Sheet 15 of 15
`
`6,005,942
`
`z LJj
`Q....J
`-
`co
`I- <(
`<( I-
`0:::)
`_J (.)
`0.. LJj
`0.. ><
`<( LJj
`
`Jl
`
`CV')
`T"""
`
`(9 -
`
`LL
`
`"
`
`-
`
`0
`...----
`("')
`00
`0
`("')
`
`z
`z~
`<(
`-
`<( 0
`~Cl
`0 >-
`Cl I-
`o-
`0::: 0:::
`<( ::)
`(.) (.)
`LJj
`CJ)
`
`>-
`
`LJj
`~
`z
`0
`-
`I-
`0..
`>-
`0:::
`(.)
`z
`
`LJj
`
`~
`
`~
`
`'l
`
`_J
`_J
`<(
`I-
`CJ)
`z
`-
`LJj
`0:::
`::)
`(.)
`LJj
`CJ)
`
`>-
`
`LJj
`~
`LJj
`0:::
`::)
`I-
`<(
`z
`-
`(9
`CJ)
`(.)
`<(
`~
`
`-
`
`H
`
`Jl
`
`>-
`
`LJj
`~
`z
`0
`I-
`t:S
`_J
`<(
`I-
`
`z -
`
`GOOG-1008
`GOOGLE LLC v. RFCYBER CORP. / Page 17 of 34
`
`

`

`6,005,942
`
`1
`SYSTEM AND METHOD FOR A MULTI(cid:173)
`APPLICATION SMART CARD WHICH CAN
`FACILITATE A POST-ISSUANCE
`DOWNLOAD OF AN APPLICATION ONTO
`THE SMART CARD
`
`CROSS REFERENCE TO RELATED
`APPLICATIONS
`
`This application claims priority to U.S. provisional appli(cid:173)
`cation Ser. No. 60/061,763 filed Oct. 14, 1997, which is
`herein incorporated by reference. This application further
`claims priority to U.S. provisional application Ser. No.
`60/041,468 filed Mar. 24, 1997, which is also herein incor(cid:173)
`porated by reference.
`This application is related to U.S. application Ser. No.
`09/046,994, filed on Mar. 24, 1998 which is also herein
`incorporated by reference for all purposes.
`
`FIELD OF THE INVENTION
`
`The present invention relates to smart cards. In particular,
`the present invention relates to a system and method for
`providing a multi-application smart card which can facilitate
`a post-issuance download of an application onto the smart
`card.
`
`BACKGROUND OF THE INVENTION
`
`A smart card is typically a credit card-sized plastic card
`that includes a semiconductor chip capable of holding data
`supporting multiple applications.
`Physically, a smart card often resembles a traditional
`"credit" card having one or more semiconductor devices
`attached to a module embedded in the card, providing
`contacts to the outside world. The card can interface with a
`point-of-sale terminal, an ATM, or a card reader integrated
`into a telephone, a computer, a vending machine, or any
`other appliance.
`A micro-controller semiconductor device embedded in a
`"processor" smart card allows the card to undertake a range
`of computational operations, protected storage, encryption
`and decision making. Such a micro-controller typically
`includes a microprocessor, memory, and other functional
`hardware elements. Various types of cards are described in
`"The Advanced Card Report: Smart Card Primer", Kenneth
`R. Ayer and Joseph F. Schuler, The Schuler Consultancy,
`1993.
`One example of a smart card implemented as a processor
`card is illustrated in FIG. 1. Of course, a smart card may be
`implemented in many ways, and need not necessarily
`include a microprocessor or other features. The smart card
`may be programmed with various types of functionality,
`including applications such as stored-value; credit/debit;
`loyalty programs, etc.
`In some embodiments, smart card 5 has an embedded
`micro-controller 10 that includes a microprocessor 12, ran(cid:173)
`dom access memory (RAM) 14, read-only memory (ROM)
`16, non-volatile memory 18, a cryptographic module 22, and
`a card reader interface 24. Other features of the micro(cid:173)
`controller may be present but are not shown, such as a clock,
`a random number generator, interrupt control, control logic,
`a charge pump, power connections, and interface contacts
`that allow the card to communicate with the outside world.
`Microprocessor 12 is any suitable central processing unit
`for executing commands and controlling the device. RAM
`14 serves as storage for calculated results and as stack
`memory. ROM 16 stores the operating system, fixed data,
`
`25
`
`2
`standard routines, and look up tables. Non-volatile memory
`18 (such as EPROM or EEPROM) serves t o store infor(cid:173)
`mation that must not be lost when the card is disconnected
`from a power source but that must also be alterable to
`5 accommodate data specific to individual cards or any
`changes possible over the card lifetime. This information
`might include a card identification number, a personal
`identification number, authorization levels, cash balances,
`credit limits, etc. Cryptographic module 22 is an optional
`10 hardware module used for performing a variety of crypto(cid:173)
`graphic algorithms. Card reader interface 24 includes the
`software and hardware necessary for communication with
`the outside world. A wide variety of interfaces are possible.
`By way of example, interface 24 may provide a contact
`15 interface, a close-coupled interface, a remote-coupled
`interface, or a variety of other interfaces. With a contact
`interface, signals from the micro-controller are routed to a
`number of metal contacts on the outside of the card which
`come in physical contact with similar contacts of a card
`20 reader device.
`Various mechanical and electrical characteristics of smart
`card 5 and aspects of its interaction with a card reading
`device are defined by the following specifications, all of
`which are herein incorporated by reference.
`Visa Integrated Circuit Card Specification, (Visa Interna(cid:173)
`tional Service Association 1996).
`EMV Integrated Circuit Card Specification for Payment
`Systems, (Visa International Service Association 1996).
`EMV Integrated Circuit Card Terminal Specification for
`30 Payment Systems, (Visa International Service Association
`1996).
`EMV Integrated Circuit Card Application Specification
`for Payment Systems, (Visa International Service Associa-
`35 tion 1996).
`International Standard, Identification Cards-Integrated
`Circuit(s) Cards with Contacts, Parts l-6 (International
`Standards Organization 1987-1995).
`Prior to issuance of a smart card to a card user, the smart
`40 card is initialized such that some data is placed in the card.
`Initialization refers to the population of non-volatile
`memory with data that is common to a large number of cards
`while also including a minimal amount of card unique terms
`(e.g. card serial number and personalization keys). For
`45 example, during initialization, the smart card may be loaded
`with at least one application, such as credit or stored cash
`value, a file structure initialized with default values, and
`some initial cryptographic keys for transport security. Once
`a card is initialized, it is typically personalized. During
`50 personalization, the smart card is loaded with data which
`uniquely identifies the card. For example, the personaliza(cid:173)
`tion data can include a maximum value of the card, a
`personal identification number (PIN), the currency in which
`the card is valid, the expiration date of the card, and
`55 cryptographic keys for the card.
`A limitation of conventional smart cards is that new
`applications typically can not be added to an issued smart
`card. Smart cards are traditionally issued with one or more
`applications predefined and installed during the manufac-
`60 turing process of the card. As a result, with traditional smart
`card implementation, once a card has been issued to a card
`user, the smart card becomes a fixed application card. If a
`new application is desired, the smart card is typically
`discarded and a new smart card, which includes the new
`65 application, is issued.
`It would be desirable to provide a smart card which would
`allow applications to be loaded after the card is issued.
`
`GOOG-1008
`GOOGLE LLC v. RFCYBER CORP. / Page 18 of 34
`
`

`

`6,005,942
`
`3
`Further, it is desirable to provide a mechanism to manage the
`loading of an application as well as general management of
`the applications on the smart card. Additionally, it is desir(cid:173)
`able to allow an application provider to keep cryptographic
`keys confidential from the issuer of the smart card and to 5
`securely allow applications from different entities to coexist
`on a card.
`
`4
`FIG. 7B is a flow diagram illustrating a sequence of card
`life states.
`FIG. 8 is an illustration of an example of a card life cycle.
`FIG. 9 is a flow diagram of an example of a method
`according to an embodiment of the present invention for
`blocking a card utilizing a card domain.
`FIG. 10 is a block diagram illustrating interactions
`between a card domain and a security domain on a smart
`10 card according to an embodiment of the present invention.
`FIGS. llA and llB are flow diagrams of an example of
`a method according to an embodiment of the present inven(cid:173)
`tion for loading an application by using a security domain
`after the smart card has issued.
`FIGS. 12A-12B are flow diagrams of an example of a
`method according to an alternate embodiment of the present
`invention for loading an application using a security domain
`after the smart card has issued.
`FIG. 13 is a block diagram illustrating an example of key
`20 management and key dependencies for post issuance down(cid:173)
`load of applications onto the smart card.
`
`DETAILED DESCRIPTION OF THE
`PREFERRED EMBODIMENTS
`
`SUMMARY OF THE INVENTION
`Embodiments of the present invention teach a system and
`method which allow card issuers to add applications during
`the lifetime of the card after the card has already been issued
`(referred to herein as post issuance loading). Downloading
`an application after the card has been issued to the card
`holder will be referred to herein as a "secure install" process. 15
`The system and method according to embodiments of the
`present invention allow the post issuance loading of an
`application and/or objects from an application server via a
`card acceptance device and its supporting system infrastruc(cid:173)
`ture delivery mechanism onto a card in a secure and confi(cid:173)
`dential manner.
`An embodiment of the present invention provides a
`system and method for controlling at least one function
`associated with an issued smart card. In a multiapplication
`smart card, a privileged application, herein referred to as a 25
`card domain, manages multiple functions related to the
`smart card. Examples of these functions include card
`initialization, global card data, card life cycle, and secure
`installation of smart card applications.
`A method according to an embodiment of the present 30
`invention for providing a first application onto an issued
`smart card comprises the steps of forwarding the first
`application to the issued smart card; and loading the first
`application onto the issued smart card, wherein the loading
`of the first application is managed by a second application.
`In another aspect of the invention, a system according to
`an embodiment of the present invention for controlling at
`least one function associated with an issued smart card is
`disclosed. The system comprises a first application associ-
`ated with the issued smart card; and a second application
`associated with the issued smart card, the second application
`being in communication with the first application, wherein
`the second application manages at least one function asso(cid:173)
`ciated with the first application.
`
`35
`
`40
`
`50
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`FIG. 1 is a block diagram of a smart card system suitable
`for implementing the present invention.
`FIG. 2 is an example of a block diagram of software layers
`which can be utilized in a smart card.
`FIGS. 3A-3B are block diagrams of examples of software
`layers according to embodiments of the present invention.
`FIG. 4 is a flow diagram of an example of a method
`according to an embodiment of the present invention for 55
`installing an application onto an issued smart card utilizing
`a card domain.
`FIG. 5 is a flow diagram of a method according to an
`embodiment of the present invention for providing confi(cid:173)
`dential information to an application in a smart card using 60
`security domains.
`FIG. 6 is a flow diagram of an example of a method
`according to an embodiment of the present invention for
`installing an application onto an issued smart card utilizing
`a card domain.
`FIG. 7A is a flow diagram illustrating a sequence of card
`life states.
`
`The following description is presented to enable one of
`ordinary skill in the art to make and to use the invention and
`is provided in the context of a patent application and its
`requirements. Various modifications to the preferred
`embodiments will be readily apparent to those skilled in the
`art and the generic principles herein may be applied to other
`embodiments. Thus, the present invention is not intended to
`be limited to the embodiment shown but is to be accorded
`the widest scope consistent with the principles and features
`described herein.
`FIG. 2 is a block diagram of an example of software layers
`which can be utilized in a smart card. The smart card shown
`in FIG. 2 includes an operating system 200, a card applica(cid:173)
`tion programming interface (API) 204, and applications
`206A-206B. Operating system 200 can include functional(cid:173)
`ity to control the cards, memory management, input/output
`(1/0), and cryptographic features. Card API 204 utilizes the
`instructions from operating system 200 and writes these
`instructions into blocks which can be reused for common
`45 routines in multiple applications. Applications 206A and
`206B can run on the smart card via instructions from API
`204. These applications can include any application which
`can run on a smart card, such as stored value, credit, debit,
`transit, and loyalty.
`One embodiment of the present invention is based upon
`the Java Card standard. In this case applications are referred
`to as' Applets' and they are written to link to a Java CardAPI
`which is the application programming interface present on
`smart cards built to the Java Card standard.
`Although the conventional software system shown in
`FIG. 2 allows for multiple applications, it does not solve the
`problem of how to securely load an application after issu(cid:173)
`ance of the smart card to a user. If an application is to be
`loaded post issuance, a mechanism is needed to manage the
`loading of an application as well as the general management
`of the applications on the smart card. Additionally, an
`application provider may wish to keep cryptographic keys
`confidential from the issuer of the smart card. Accordingly,
`a mechanism is needed to provide for the separation of
`65 confidential information between an application provider
`and an issuer of a smart card. Embodiments of the present
`invention address such a need.
`
`GOOG-1008
`GOOGLE LLC v. RFCYBER CORP. / Page 19 of 34
`
`

`

`6,005,942
`
`5
`FIGS. 3A-3B are block diagrams showing software com(cid:173)
`ponents of a smart card according to embodiments of the
`present invention. The arrows indicate dependencies
`between components. FIG. 3A shows an embodiment of a
`smart card utilizing a card domain, while FIG. 3B shows an
`embodiment of a smart card utilizing a security domain, as
`well as a card domain.
`The example shown in FIG. 3A includes an operating
`system 300, a card API 304, applications 305A-305C, a card
`domain 308, and open platform (OP) API 306. The system
`shown in FIG. 3 allows for a secure and managed post
`issuance download of an application onto a smart card. A
`card domain is a card issuier's on-card control mechanism
`for a smart card according to the present invention.
`Open platform API 306 classifies instructions into card
`domain 308 and security domains 310A-310B (shown in
`FIG. 3B). Accordingly, OP API 306 facilitates the formation
`of instructions into sets which can be identified as being
`included as part of card domain 308 and security domains
`310A-310B.
`Applications 305A-305C can include any application
`which can be supported by a smart card. Examples of these
`applications include credit, debit, stored value, transit, and
`loyalty. Applications 305A-305C are shown to include
`command interfaces, such as APDU interfaces 354A-354C
`which facilitate communication with the external environ(cid:173)
`ment. APDU stands for "Application Protocol Data Unit"
`and is a standard communication messaging protocol
`between a card acceptance device and a smart card. A
`command is a message sent by the terminal to the smart card
`that initiates an action and solicits a response from the smart
`card.
`Applications 305A-305C can run on the smart card via
`instructions from card API 304. Card API 304 is imple(cid:173)
`mented using the instructions from the card operating sys(cid:173)
`tem and writes these instructions into blocks which can be
`reused for common routines for multiple applications. Those
`skilled in the art will recognize that a translation layer or
`interpreter may reside between API 304 and operating
`system 300. An interpreter interprets the diverse hardware
`chip instructions from vendor specific operating system 300
`into a form which can be readily utilized by card API 304.
`Card domain 308 can be a "privileged" application which
`represents the interests of the smart card issuer. As a
`"privileged" application, card domain 308 may be config(cid:173)
`ured to perform multiple functions to manage various
`aspects of the smart card.