(12) United States Patent
`Wentker et al.
`
`USOO6481.632B2
`US 6,481,632 B2
`(10) Patent No.:
`*Nov. 19, 2002
`(45) Date of Patent:
`
`(54)
`
`(75)
`
`(73)
`
`(21)
`(22)
`(65)
`
`(60)
`
`(51)
`(52)
`
`(58)
`
`(56)
`
`DELEGATED MANAGEMENT OF SMART
`CARD APPLICATIONS
`
`Notice:
`
`ASSignee:
`
`Inventors: David C. Wentker, San Francisco, CA
`(US); Klaus P. Gungl, Sindelfingen
`(DE)
`Visa International Service
`Association, San Francisco, CA (US)
`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
`U.S.C. 154(b) by 0 days.
`
`Appl. No.: 09/427,517
`Filed:
`Oct. 26, 1999
`Prior Publication Data
`US 2002/0040936A1 Apr. 11, 2002
`Related U.S. Application Data
`Provisional application No. 60/121,810, filed on Feb. 25,
`1999, provisional application No. 60/124,130, filed on Mar.
`12, 1999, and provisional application No. 60/105,841, filed
`on Oct. 27, 1998.
`Int. Cl................................................. G06K 19/06
`U.S. Cl. ....................... 235/492; 235/376; 235/380;
`235/382; 235/487
`Field of Search ................................. 235/380, 492,
`235/487, 376, 382
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`5/1988 Turpen et al. .............. 235/487
`4,742.215 A
`5/1989 Igasawara
`4,831,245 A
`(List continued on next page.)
`FOREIGN PATENT DOCUMENTS
`
`DE
`
`196O7363
`
`9/1996
`
`(List continued on next page.)
`
`OTHER PUBLICATIONS
`
`Carol Hovenga Fancher, “In Your Pocket SmartCard', Feb.
`1997, IEEE Specturm.
`(List continued on next page.)
`
`Primary Examiner Karl D. Frech
`Assistant Examiner Seung Ho Lee
`(74) Attorney, Agent, or Firm-Beyer Weaver & Thomas,
`LLP
`ABSTRACT
`(57)
`A Smart card architecture includes a run-time environment,
`a card manager, one or more Security domains, a provider
`application and an issuer application. One or more APIs
`provide communication. The life cycle of the card and card
`manager includes States: Pre-production, Ready, Initialized,
`Secured, Locked and Terminated. The life cycle of an
`application includes States: Installed, Selectable,
`Personalized, Blocked, Locked and Deleted. A card registry
`keeps track of card manager and application data elements.
`The functionality of a Security domain on a Smart card is
`extended to allow it to perform delegated management of
`Smart card applications: delegated loading, installation and/
`or deletion of an application. A provider of an application is
`assured of more direct control and management of their
`application, yet an issuer Still maintains Some control over
`the management of the card. The card issuer empowers
`application providers to initiate changes to the issuer's Smart
`cards that are pre-approved by the card issuer. A method of
`delegated loading of an application onto a Smart card first
`receives a load command from an application provider via a
`card acceptance device. The load command includes an
`indication of an application to be loaded and an appended
`command authentication pattern. Next, the load command is
`Verified using the command authentication pattern. Then, an
`application is received from an application provider via the
`card acceptance device; the application also includes an
`appended application authentication pattern which is used to
`Verify the application. Finally, the application is loaded into
`memory of the Smart card.
`
`E10O227
`
`11/1994
`
`16 Claims, 14 Drawing Sheets
`
`Provider Security
`Provider Security
`Domain
`Domain
`108
`O6
`
`Issuer Application
`Open PlatformAPI
`112
`110
`
`Card
`Manager
`
`104
`
`Provider
`Application
`14
`
`
`
`Smart Card
`Ruintime Environment
`
`Y
`Q102
`
`?
`
`Open Platform Architecture
`
`GOOG-1007
`GOOGLE LLC v. RFCYBER CORP. / Page 1 of 30
`
`

`

`US 6,481,632 B2
`Page 2
`
`U.S. PATENT DOCUMENTS
`
`5,332,889 A 7/1994 Lundstrom et al. ......... 235/380
`5,378.884 A
`1/1995 Lundstrom et al. ......... 235/441
`5,530.232 A 6/1996 Taylor ..............
`... 235/380
`5,578,808 A * 11/1996 Taylor ...
`... 235/380
`5,583,933 A 12/1996 Mark .....
`... 379/355
`5,901,303 A 5/1999 Chew ......................... 395/400
`5,923,884 A * 7/1999 Pryret et al. ................ 395/712
`6,005.942 A * 12/1999 Chan et al. ....
`... 235/380
`6,164,549 A * 12/2000 Richards .......
`... 235/492
`6,167,521. A 12/2000 Smith et al. ................ 713/200
`FOREIGN PATENT DOCUMENTS
`
`
`
`EP
`EP
`EP
`EP
`WO
`
`O193635
`O658862
`O795844
`O798673
`98/.43212
`
`9/1986
`6/1995
`9/1997
`10/1997
`10/1998
`
`OTHER PUBLICATIONS
`Chaum et al., “SmartCard 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 Unobstrusive
`Inroads”, Aug. 1996, Scientific American Website.
`Jerome Svigals, “Smart Cards The New Bank Cards”, 1985,
`MacMillan Publishing Company.
`Roy Bright, “SmartCards: Principles, Practice, Applica
`tions”, 1998, Ellis Horwood Limited.
`Jerome Svigals, “SmartCards The Ultimate Personal Com
`puter”, 1985, MacMillan Publishing Company.
`Hawkes et al., “Integrated Circuit Cards, Tags and Tokens',
`1990, BSP Professional Books.
`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 I: Concepts and Structures”, 1994, European
`Standard, prEN 1546.
`“Identification Card Systems-Inter-Sector Electronic
`Purse Part 2: Security Architecture”, 1994, European Stan
`dard, prEN XXXXX-2.
`“Identification Card System-Inter-Sector Electronic Purse
`Part 3: Data Elements and Interchanges”, 1994, European
`Prestandard, prEN 1546–3.
`“Identification Card System-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
`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 781 6–2, First Edition.
`“Identification Cards-Integrated Circuit(s) Cards With
`Contacts Part 3: Electronic Signals and Transmission Pro
`tocols', International Standard, ISO/IEC 7816-3, First Edi
`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
`cedure for Application Identifiers”, 1993, International Stan
`dard, ISO/IEC DIS 7816–5.
`“International Cards-Integrated Circuit(s) Cards With
`Contacts Part 6: Inter-Industry Data Elements”, 1995, Inter
`national Standard, ISO/IEC DIS 7816–6.
`“Bank Cards-Magnetic Stripe Data Content For Track 3”,
`1987, International Standard, ISO 4909 Second Edition.
`“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.
`“Identification Cars-Recording Technique-Part 2: Mag
`netic Strip”, 1995, International Standard, ISO/IEC 7811–2,
`Second Edition.
`“Identification Cards-Recording Technique-Part 3: Loca
`tion of Embossed Characters on ID-1 Cards', 1995, Inter
`national Standard, ISO/IEC 7811-5, Second Edition.
`“Identification Cards-Recording Technique-Part 4: Loca
`tion of Read-Only Magnetic Tracks-Tracks 1 & 2, 1995,
`International Standard, ISO/IEC 7811-4, Second Edition.
`“Identification Cards-Recording Technique-Part 5: Loca
`tion of Read-Write Magnetic Track Track 3”, Interna
`tional Standard, ISO/IEC 7811–5, Second Edition.
`“Identification Cards-Recording Technique-Part 6: Mag
`netic Stripe-High Coercivity”, 1996, International Standard,
`ISO/IEC 7811–6, First Edition.
`“Identification Cards-Financial Transaction Cards”, 1990,
`International Standard, ISO/IEC 7813, Third Edition.
`“Identification Cards-Financial Transaction Cards Amend
`ment 1' 1996, International Standard, ISO/IEC 7813, Fourth
`Edition.
`“Identification Cards-Contactless Integrated Circuit(s)
`Cards-Part 1: Physical Characteristics”, 1992, Interna
`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.
`“Identification Cards-Contactless Integrated Circuit(s)
`Cards-Part 3: Electronic Signals and Reset Procedures”,
`1996, International Standard, ISO/IEC 10536–3, First Edi
`tion.
`“Financial Transaction Cards-Security Architecture of
`Financial Transaction System Using Integrated Circuit
`Cards-Part 1: Card Life Cycle”, Sep. 15, 1991, Interna
`tional Standard, ISO/IEC 10202–1, First Edition.
`Hiro Shogase, “The Very Smart Card: A Plastic Pocket
`Bank”, IEEE Sepctrum, Oct. 1988.
`* cited by examiner
`
`GOOG-1007
`GOOGLE LLC v. RFCYBER CORP. / Page 2 of 30
`
`

`

`U.S. Patent
`
`Nov. 19, 2002
`
`Sheet 1 of 14
`
`US 6,481,632 B2
`
`
`
`Application Development
`Tools
`
`
`
`Key Management
`Systems
`
`
`
`
`
`
`
`30
`
`
`
`Acceptance
`Devices
`
`Open Platform
`Architecture
`
`Terminal
`Management
`Systems
`
`
`
`
`
`Card Management
`Systems
`
`26
`
`Application Services
`
`42 OE 2
`2. 28
`Personalization Systems
`
`FG. 1
`
`GOOG-1007
`GOOGLE LLC v. RFCYBER CORP. / Page 3 of 30
`
`

`

`U.S. Patent
`
`Nov. 19, 2002
`
`Sheet 2 of 14
`
`US 6,481,632 B2
`
`Provider Security
`Provider Security
`DOmain
`Domain
`108
`106
`
`
`
`issuer Application
`Open Platform AP
`112
`110
`
`102
`
`Open Platform Architecture
`
`FIG 2
`
`GOOG-1007
`GOOGLE LLC v. RFCYBER CORP. / Page 4 of 30
`
`

`

`U.S. Patent
`
`Nov. 19, 2002
`
`Sheet 3 of 14
`
`US 6,481,632 B2
`
`
`
`
`
`
`
`
`
`
`
`104.
`
`Card Manager
`
`106
`
`108
`
`Open Platform
`AP
`
`Provider
`Application
`114
`
`
`
`Issuer
`Application
`112
`
`Provider
`Application
`116
`
`Hardware Independent AP
`
`122
`
`
`
`
`
`Smart Card Operating System
`
`120
`
`FIG 3
`
`GOOG-1007
`GOOGLE LLC v. RFCYBER CORP. / Page 5 of 30
`
`

`

`U.S. Patent
`
`Nov. 19, 2002
`
`Sheet 4 of 14
`
`US 6,481,632 B2
`
`
`
`
`
`
`
`
`
`204
`
`2O6
`
`208
`
`, SECURED
`
`CM LOCKED
`
`210
`
`TERMINATED
`
`212
`
`a-
`
`Card Manager Life Cycle
`
`FIG. 4
`
`GOOG-1007
`GOOGLE LLC v. RFCYBER CORP. / Page 6 of 30
`
`

`

`U.S. Patent
`
`Nov. 19, 2002
`
`Sheet 5 of 14
`
`US 6,481,632 B2
`
`
`
`NSTALLED
`
`
`
`
`
`SELECTABLE
`
`PERSONALIZED
`
`BLOCKED
`
`
`
`
`
`
`
`LOCKED
`
`LOGICALLY
`DELETED
`
`
`
`Physically deleted
`
`Application Life Cycle
`
`FIG. 5
`
`GOOG-1007
`GOOGLE LLC v. RFCYBER CORP. / Page 7 of 30
`
`

`

`U.S. Patent
`
`Nov. 19, 2002
`
`Sheet 6 of 14
`
`US 6,481,632 B2
`
`
`
`Card Manager AID
`
`Card Manager Life Cycle State
`
`Card Manager Data Elements
`
`Security Domain AD
`
`Application Data Elements
`
`/
`
`Card Registry
`
`FIG. 6
`
`GOOG-1007
`GOOGLE LLC v. RFCYBER CORP. / Page 8 of 30
`
`

`

`U.S. Patent
`
`Nov. 19, 2002
`
`Sheet 7 of 14
`
`US 6,481,632 B2
`
`
`
`DELEGATED LOADING
`
`302
`
`
`
`
`
`
`
`
`
`SMART CARD
`PRODUCED WITH
`SECURITY DOMAINS
`
`
`
`
`
`
`
`306
`
`
`
`
`
`31 O
`
`
`
`314
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`SMART CARD IS
`ACTIVATED
`
`PROVIDER WRITES
`APPLICATION
`
`SECURITY DOMAIN
`ASSIGNED TO
`APPLICATION
`PROVIDER
`
`
`
`
`
`
`
`
`
`318
`
`APPLICATION
`PROVIDER RECEIVES
`SECURITY DOMAIN
`KEYS
`
`
`
`
`
`ISSUER
`AEYö,
`(FIG. 7B)
`
`
`
`322
`
`
`
`326
`
`CARD INSERTED
`INTO CARD
`ACCEPTANCE
`DEVICE
`
`330
`
`334
`
`PROVIDER
`DOWNLOADS
`APPLICATION
`ONTO CARD
`(FIG.7C)
`
`PROVIDER
`INSTALLS
`APPLICATION
`(FIG. 7D)
`
`FG. 7A
`
`GOOG-1007
`GOOGLE LLC v. RFCYBER CORP. / Page 9 of 30
`
`

`

`U.S. Patent
`
`Nov. 19, 2002
`
`Sheet 8 of 14
`
`US 6,481,632 B2
`
`
`
`
`
`
`
`ISSUER APPROVES
`APPLICATION
`(Step 322)
`
`340
`
`348
`
`ISSUER PERFORMS
`TESTING AND
`CERTIFICATION OF
`APPLICATION
`
`342
`
`344
`
`CREATE DATA
`AUTHENTICATION
`PATTERN FOR
`APPLICATION
`
`DETERMINE
`APPLICATION GENERAL
`CHARACTERISTICS
`
`346
`
`
`
`CREATE COMMAND FOR
`APPLICATION LOADING
`
`ADD DATA AUTHENTICATION
`PATTERN TO LOAD COMMAND
`
`350
`
`352
`
`DETERMINE
`INSTALLATION
`BEHAVOR OF
`APPLICATION
`
`CREATE COMMAND
`FOR APPLICATION
`INSTALLATION
`
`354
`
`ADD DATA
`AUTHENTICATION
`PATTERN TO INSTALL
`COMMAND
`
`
`
`356
`
`DELIVER
`APPLICATION AND
`COMMANDS TO
`PROVIDER
`
`FIG. 7B
`
`GOOG-1007
`GOOGLE LLC v. RFCYBER CORP. / Page 10 of 30
`
`

`

`U.S. Patent
`
`Nov. 19, 2002
`
`Sheet 9 of 14
`
`US 6,481,632 B2
`
`DOWNLOAD
`APPLICATION ONTO
`CARD
`(Step 330)
`
`
`
`
`
`APPROVAL MESSAGE 372
`SENT TO PROVIDER
`HOST
`
`
`
`
`
`360
`
`ESTABLISH DATA LINK
`BETWEEN PROVIDER HOST
`AND CARD IN CARD
`ACCEPTANCE DEVICE
`
`HOST SENDSAPPLICATION -374
`TO SECURITY DOMAIN ON
`CARD
`
`362
`
`HOST SENDS LOAD
`COMMAND TO SECURITY
`DOMAIN ON CARD
`
`364
`
`
`
`SECURITY DOMAIN
`PASSES LOAD COMMAND
`TO CARD MANAGER
`
`366
`
`CARD MANAGER
`AUTHENTICATES LOAD
`COMMAND
`
`368
`
`CARD MANAGER
`PASSES LOAD
`COMMAND TO
`INSTALLER
`
`370
`
`INSTALLER
`PROCESSES LOAD
`COMMAND
`
`SECURITY DOMAIN
`PASSES APPLICATION
`TO CARD MANAGER
`
`376
`
`CARD MANAGER
`AUTHENTICATES
`APPLICATION
`
`378
`
`CARD MANAGER PASSES
`APPLICATION TO
`INSTALLER
`
`380
`
`INSTALLERLOADS
`APPLICATION AND LINKS
`
`382
`
`
`
`
`
`
`
`CONFIRMATION
`MESSAGE SENT TO
`PROVIDER HOST
`
`384
`
`FIG. 7C
`
`GOOG-1007
`GOOGLE LLC v. RFCYBER CORP. / Page 11 of 30
`
`

`

`U.S. Patent
`
`Nov. 19, 2002
`
`Sheet 10 of 14
`
`US 6,481,632 B2
`
`
`
`
`
`INSTALL APPLICATION
`ON CARD
`(Step 334)
`
`HOST SENDS INSTALL
`COMMAND TO SECURITY
`DOMAIN ON CARD
`
`386
`
`SECURITY DOMAIN
`PASSES INSTALL
`COMMAND TO CARD
`MANAGER
`
`388
`
`CARD MANAGER
`AUTHENTCATES INSTALL
`COMMAND
`
`390
`
`CARD MANAGER PASSES1392
`INSTALL COMMAND TO
`INSTALLER
`
`INSTALLER PROCESSEs
`NSTAL COMMAND
`
`
`
`CONFIRMATION MESSAGE
`SENT TO PROVIDER HOST
`
`396
`
`FIG. 7D
`
`GOOG-1007
`GOOGLE LLC v. RFCYBER CORP. / Page 12 of 30
`
`

`

`U.S. Patent
`
`US 6,481,632 B2
`
`
`
`pueuuuuo O peoT
`
`#709
`
`909
`
`809
`
`0 | 9
`
`GOOG-1007
`GOOGLE LLC v. RFCYBER CORP. / Page 13 of 30
`
`

`

`U.S. Patent
`
`Nov. 19, 2002
`
`Sheet 12 of 14
`
`US 6,481,632 B2
`
`
`
`
`
`Load Command
`
`602
`
`Load File
`
`500
`
`
`
`
`
`Install Command
`
`520
`
`Application Provider Host Computer
`
`Card Manager
`
`
`
`APDU
`Interface
`
`612
`616
`
`Management
`Interface
`
`
`
`Installer Routine J-614
`
`Security
`Domain 610
`APDU
`Interface
`
`604
`
`FIG 11
`
`
`
`
`
`
`
`
`
`
`
`
`
`GOOG-1007
`GOOGLE LLC v. RFCYBER CORP. / Page 14 of 30
`
`

`

`U.S. Patent
`
`Nov. 19, 2002
`
`Sheet 13 of 14
`
`US 6,481,632 B2
`
`Delegated Deletion
`Host
`Security Domain
`
`Card Manager
`
`SELECT
`
`H SELECT Security Domain ->
`
`-H SELECT Response -
`
`Optional Authentication
`Process
`
`- DELETE (AD) ->
`- DELETE (AD) -->
`
`DELETE
`
`Delete Application
`
`-- Delete Receipt -
`-- DELETE Response -
`
`APDU Interface
`
`FIG. 12
`
`GOOG-1007
`GOOGLE LLC v. RFCYBER CORP. / Page 15 of 30
`
`

`

`U.S. Patent
`
`Nov. 19, 2002
`
`Sheet 14 of 14
`
`US 6,481,632 B2
`
`-R-
`
`922
`
`924
`
`926
`
`PROCESSOR(S)
`
`MEMORY
`
`FIXED DISK
`
`
`
`REMOVABLE
`DISK
`
`-
`
`904
`
`910
`
`912
`
`940
`
`DISPLAY
`
`KEYBOARD
`
`MOUSE
`
`SPEAKERS
`
`
`
`NETWORK
`INTERFACE
`
`FIG. 14
`
`GOOG-1007
`GOOGLE LLC v. RFCYBER CORP. / Page 16 of 30
`
`

`

`1
`DELEGATED MANAGEMENT OF SMART
`CARD APPLICATIONS
`
`US 6,481,632 B2
`
`2
`In addition to logistical problems, there are privacy issues
`with regard to an application developer's private customer
`data. For example, if a loyalty application of a particular
`third party is loaded onto a Smart card by the issuer, it may
`be still necessary to add private customer-specific data onto
`each individual card for use by loyalty application. This
`private customer information may very well be the private
`property of the third party, and the third party may be
`unwilling to transfer this private information to a card issuer
`to allow the card issuer to load and install the third party's
`loyalty data. For instance, Hertz would likely be unwilling
`to provide private customer information regarding it top
`renters to the bank that is loading Hertz's application onto a
`Smart card.
`Other mechanical difficulties are presented should a cus
`tomer desire to download and install a third party's appli
`cation at the third party's Site if only the issuer is allowed to
`download and install an application. For example, should a
`customer wish to download a loyalty application while at the
`third party's place of business during a Smart card
`transaction, it would be first be necessary for the card
`acceptance device to connect to the issuer host to download
`the loyalty application, and then connect to the third party's
`host computer in order to receive custom information for the
`initialization and personalization of that application. Such
`multiple connections at load time make the transaction more
`complex, time consuming and are more prone to failure. In
`addition, as a practical matter, should a customer wish to
`download and install an application onto his Smart card, it is
`more than likely that the customer is physically present at a
`third party site rather than at the issuer's Site.
`Further difficulties may be encountered if only the issuer
`is allowed to delete an application that belongs to the
`application provider/developer from a customer Smart card.
`For example, the application is the responsibility of the
`application provider and is his liability. Should an agreement
`expire between the provider and the issuer, it may be more
`desirable for the provider to be able to delete his property
`(the application) from the Smart card, rather than relying
`upon the issuer to do so for him. A further difficulty
`encountered if only the issuer is allowed to delete an
`application relates to the application data. When an appli
`cation is deleted, the application data is deleted as well.
`Therefore, it would be desirable to allow the application
`provider to extract any relevant data (e.g., loyalty points
`from a loyalty application) from the card before the appli
`cation is deleted. Since the card issuer does not have the
`provider's application keys, it would be near impossible for
`the card issuer to extract any information that required any
`kind of authentication. (The provider may also not desire
`that the issuer have access to the extracted information.)
`Therefore, it would be desirable to allow another entity
`besides the card issuer to manage various functions associ
`ated with card applications Such as loading, installing and
`deleting. It would further be desirable to allow the issuer to
`Still be able to manage and control which applications are
`present on the Smart card.
`
`60
`
`65
`
`SUMMARY OF THE INVENTION
`To achieve the foregoing, and in accordance with the
`purpose of the present invention, a technique is disclosed
`that extends the functionality of a Security domain and
`allows it to perform delegated management of Smart card
`applications. For example, embodiments of the present
`invention allow a Security domain to perform delegated
`loading, installation and/or deletion of an application. By
`
`This application claims priority of U.S. provisional
`patent application Nos. 60/105,841, 60/121,810 and 60/124,
`130 filed Oct. 27, 1998, Feb. 25, 1999 and Mar. 12, 1999
`respectively, each entitled “Visa Open Platform Card
`Specification,” which are hereby incorporated by reference.
`This application is also related to U.S. patent application
`Ser. Nos. 09/046,993 and 09/046,994.
`FIELD OF THE INVENTION
`The present invention relates generally to Smart cards.
`More specifically, the present invention relates to a tech
`nique for delegating the management of applications on a
`Smart card Such as loading, installation and deletion.
`BACKGROUND OF THE INVENTION
`Smart card technologies hold great promise as the
`replacement for magnetic Stripe card technology. The adop
`tion of Smart cards, however, on a massive Scale has been
`slow to develop. One reason for this slow adoption is the
`lack of Standards among the many different vendor imple
`mentations of Smart cards and the difficulties with imple
`menting a new technology.
`Recently, Significant Standards in the Smart card area have
`been created. The Standards, however, have been primarily
`targeted at either low levels of interoperability, Such as the
`mechanical and electrical standards specified in the EMV
`Specifications, or at the application layer in terms of devel
`oping Standard chip credit, debit and purse applications. The
`main benefit of the Standards has been realized in Single
`application Smart cards, but has not significantly improved
`the situation for multi-applications Smart cards.
`The mid-1990s saw the introduction of various open
`Systems Standards for application development. For
`example, three technologies in this area are JAVA Card from
`Sun Microsystems, Inc., Smart Card for Windows from
`Microsoft Corporation, and MULTOS from MAOSCO, Ltd.
`These technology Standards provide an important part of the
`Solution toward common programming Standards allowing
`application portability between different manufacturers card
`implementations. Other recent efforts have also addressed
`particular issues with multi-application Smart cards. For
`example, U.S. patent application Ser. No. 09/046,994 filed
`Mar. 24, 1998, and U.S. patent application Ser. No. 09/046,
`993 filed Mar. 4, 1998 address issues related to post-issuance
`downloading and life cycle, each of which are hereby
`incorporated by reference.
`In prior art Smart cards only the issuer of the card has been
`allowed to perform certain management functions of appli
`cations Such as loading an application onto the card, install
`ing the application and deleting the application from the
`card. This reliance upon the issuer exclusively for loading,
`installing and deleting applications can lead to Some diffi
`culties. For example, should a Store develop a loyalty
`application for its customers that it wishes to load and install
`onto their customer's Smart cards, the Store would be pre
`cluded from doing So if only the card issuer is allowed to
`perform Such functions. Arranging for the Store to contact
`the issuer, and arranging for the issuer to load the Store's
`application onto its customer's Smart cards presents basic
`logistical problems Such as application Security and acceSS
`to cards. For example, it would be best if the store could
`download an application onto a customer card while the
`customer Visited the Store. If only the issuer can download
`the application, it becomes more difficult to access the
`customer card.
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`GOOG-1007
`GOOGLE LLC v. RFCYBER CORP. / Page 17 of 30
`
`

`

`3
`delegating this management to their Security domain, a
`provider of an application is assured of more direct control
`and management of their application, yet an issuer Still
`maintains Some control over the management of the card.
`This concept of delegated management allows the card
`issuer the option of empowering application providers to
`initiate changes to the issuer's Smart cards that are pre
`approved by the card issuer. This pre-approval ensures that
`only card content changes that the card issuer has approved
`will be accepted and processed by a card manager of a Smart
`card. This delegation of control in the card update proceSS
`allows application providers more flexibility in managing
`their own applications on the card issuer's cards.
`In one embodiment, a method of delegated loading of an
`application onto a Smart card first receives a load command
`from an application provider via a card acceptance device.
`The load command includes an indication of an application
`to be loaded and an appended command authentication
`pattern. Next, the load command is verified using the
`command authentication pattern. Then, an application is
`received from an application provider via the card accep
`tance device; the application also includes an appended
`application authentication pattern which is used to verify the
`application. Finally, the application is loaded into memory
`of the Smart card. Thus, an application provider is allowed
`to load an application onto a Smart card.
`In another embodiment, a System for delegated loading of
`an application onto a Smart card includes a host computer
`under control of an application provider and a Software
`application to be loaded onto a Smart card. The application
`includes an appended application authentication pattern pro
`duced by an issuer of the Smart card that verifies the
`application to the Smart card. The System also includes a
`Smart card acceptance device linked to the host computer
`and a Smart card included in the card acceptance device. The
`Smart card includes code arranged to Verify the application
`using the application authentication pattern. Thus, the appli
`cation provider is allowed to load the application onto the
`Smart card.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`The invention, together with further advantages thereof,
`may best be understood by reference to the following
`description taken in conjunction with the accompanying
`drawings in which:
`FIG. 1 illustrates symbolically and environment in which
`the Open Platform architecture provides benefits for Smart
`card holders, issuers, application developerS and other enti
`ties.
`FIG. 2 illustrates in further detail the Open Platform
`architecture as it may be implemented upon a Smart card.
`FIG. 3 is another illustration of the Open Platform archi
`tecture of FIG. 2 Suitable for explaining the present inven
`tion.
`FIG. 4 illustrates the card manager life cycle State tran
`Sitions according to one embodiment of the invention.
`FIG. 5 illustrates application life cycle state transitions
`according to one embodiment of the invention.
`FIG. 6 illustrate a card registry database according to one
`embodiment of the invention.
`FIG. 7A is a flow diagram describing a technique for
`performing delegated loading.
`FIG. 7B is a flow diagram that describes how an issuer
`approves an application for delegated loading and installa
`tion.
`
`1O
`
`15
`
`25
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`US 6,481,632 B2
`
`4
`FIG. 7C is a flow diagram describing one embodiment of
`the download application step of FIG. 7A.
`FIG. 7D is a flow diagram describing the install applica
`tion step of FIG. 7A.
`FIGS. 8 and 9 illustrate examples of a load and an install
`command that may be created in steps 346 and 352 of FIG.
`7B.
`FIG. 10 illustrates a load file containing an application
`according to one embodiment of the invention.
`FIG. 11 illustrates an embodiment in which an application
`may be downloaded from an application provider host
`computer to a Smart card in a delegated manner.
`FIG. 12 is a flow diagram describing a technique for
`performing delegated deletion.
`FIGS. 13 and 14 illustrate a computer system suitable for
`implementing embodiments of the present invention.
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`The present invention is Suitable for use with either Single
`or multi-application Smart cards. A multi-application Smart
`card may come from a variety of manufacturers and may use
`any of a number of operating Systems. By way of example,
`a Smart card may use the JAVA Card operating System or the
`Smart Card for Windows operating system. As used herein,
`“Smart card” refers to any of these single-application or
`multi-application Smart cards. In one particular
`embodiment, the present invention works well with the
`“Open Platform' architecture as defined in Open Platform
`Card Specification Version 2.0, Apr. 19, 1999, available
`from Visa International Service ASSociation. This architec
`ture in one embodiment is based upon the JAVA Card
`operating System and provides a hardware-neutral, Vendor
`neutral, application-independent card management Standard.
`The Standard provides a common Security and card man
`agement architecture and defines a flexible and powerful
`Standard for card issuers to create multi-application Smart
`cards.
`
`Smart Cards
`The present invention is applicable to Smart cards. Also
`termed chip cards, integrated circuit cards, memory cards or
`processor cards, a Smart card is typically a credit card-sized
`plastic card that includes one or more Semiconductor inte
`grated circuits. A Smart card can interface with a point-of
`Sale terminal, an ATM, or with a card reader integrated with
`a computer, telephone, Vending machine, or a variety of
`other devices. The Smart card may be programmed with
`various types of functionality Such as a Stored-value
`application, a credit or debit application, a loyalty
`application, cardholder information, etc. Although a plastic
`card is currently the medium of choice for Smart cards, it is
`contemplated that a Smart card may also be implemented in
`a Smaller form factor, for example, it may attach to a key
`chain or be as Small as a chip module. A Smart card may also
`be implemented as part of a personal digital assistant,
`telephone (Such as a Subscriber identification module), or
`take a different form. The below description provides an
`example of the possible elements of a Smart card, although
`the present invention is applicable to a wide range of types
`of Smart cards.
`A Smart card may include a microprocessor, random
`access memory (RAM), read-only memory (ROM), non
`volatile memory, an encryption module (or arithmetic unit),
`and a card reader (or terminal) interface. Other features may
`
`GOOG-1007
`GOOGLE LLC v. RFCYBER CORP. / Page 18 of 30
`
`

`

`US 6,481,632 B2
`
`15
`
`25
`
`35
`
`40
`
`S
`be present such as optical storage, flash EEPROM, FRAM,
`a clock, a random number generator, interrupt control,
`control logic, a charge pump, power connections, and inter
`face contacts that allow the card to communicate with the
`outside world. Of course, a Smart card may be implemented
`in many ways, and need not necessarily include a micro
`processor or other features.
`The microprocessor is any Suitable central processing unit
`for executing commands and controlling the device. RAM
`Serves as temporary Storage for calculated results and as
`Stack memory. ROM Stores the operating System, fixed data,
`Standard routines, look up tables and other permanent infor
`mation. Non-volatile memory (such as EPROM or
`EEPROM) serves to store information that must not be lost
`when the card is disconnected from a power Source, and
`must also be alterable to accommodate data Specific to
`individual cards or changes possible over the card lifetime.
`This information includes a card identification number, a
`personal identification number, authorization levels, cash
`balances, credit limits, and other information that may need
`to change over time. An encryption module is an optional
`hardware module used for performing a variety of encryp
`tion algorithms. Of course, encryption may also be per
`formed in Software. Applied Cryptography, Bruce Schneier,
`John Wiley & Sons, Inc., 1996 discusses suitable encryption
`algorithms and is hereby incorporated by reference.
`The card reader interface includes the Software and hard
`ware necessary for communication with the outside world.
`A wide variety of interfaces are possible. By way of
`example, the interface may provide a contact interface, a
`close-coupled interface, a remote-coupled interface, or a
`variety of other interfaces. With a contact interface, Signals
`from the integrated circuit 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 reader device. A Smart
`card may include a traditional magnetic Stripe to provide
`compatibility with traditional card reader devices and
`applications, and may also provide a copy of the magnetic
`Stripe information within the integrated circuit itself for
`compatibility.
`Various mechanical and electrical characteristics of a
`Smart card and aspects of its interaction with a card reader
`device are described in Smart Card Handbook, W. Rankland
`W. Effing, John Wiley & Sons, Ltd., 1997, and are defined
`by the following Specifications, all of which are incorporated
`herein by reference: Visa Integrated Circuit Card
`Specification, Visa International Service Association, 1996;
`EMV Integrated Circuit Card Specification for Payment
`Systems, EMV Integrated Circuit Card Terminal Specifica
`tion for Payment Systems, EMV Integrated Circuit Card
`Application Specification for Payment Systems, Visa
`International, Mastercard, Europay, 1996; and International
`Standard; Identification Card