`(12) Patent Application Publication (10) Pub. No.: US 2006/0196931 A1
`(43) Pub. Date:
`Sep. 7, 2006
`Holtmanns et al.
`
`US 2006O196931A1
`
`(54) METHODS, SYSTEM AND MOBILE DEVICE
`CAPABLE OF ENABLING CREDIT CARD
`PERSONALIZATION USING AWIRELESS
`NETWORK
`
`(75) Inventors: Silke Holtmanns, Vantaa (FI); Pekka
`Laitinen, Helsinki (FI)
`Correspondence Address:
`ALSTON & BIRD LLP
`BANK OF AMERICA PLAZA
`101 SOUTH TRYON STREET, SUITE 4000
`CHARLOTTE, NC 28280-4000 (US)
`(73) Assignee: Nokia Corporation, Espoo (FI)
`
`(21) Appl. No.:
`(22) Filed:
`
`11/237,811
`Sep. 28, 2005
`Related U.S. Application Data
`(60) Provisional application No. 60/659,258, filed on Mar.
`7, 2005.
`
`Publication Classification
`
`(51) Int. Cl.
`(2006.01)
`G06K 5/00
`(52) U.S. Cl. .............................................................. 235/38O
`
`(57)
`
`ABSTRACT
`
`Methods of creating a secure channel over which credit card
`personalization data can be transmitted over the air (OTA)
`are provided. In particular, Generic Authentication Archi
`tecture (GAA) may be used to establish a secure commu
`nication channel between the user equipment (UE) and a
`personalization application server or bureau acting as a
`network application function (NAF) server. An user equip
`ment, personalization application service (e.g., a NAF
`server), a system embodying a personalization application
`server and an user equipment, and a computer program
`product are also provided for creating a secure channel. Such
`as via GAA, over which credit card personalization data can
`be transmitted OTA.
`
`61O
`
`620
`
`632
`
`634
`
`EMV
`
`GBA
`
`Secure
`Core
`Generated
`Shared
`Secret Keys
`
`
`
`Payment or
`Ticketing
`Application
`
`612
`
`614
`
`UCC
`
`EMV U
`
`GBA U
`
`ldentification
`Information
`
`622
`
`624
`
`626
`
`IPR2022-00412
`Apple EX1039 Page 1
`
`
`
`Patent Application Publication Sep. 7, 2006 Sheet 1 of 14
`
`US 2006/0196931 A1
`
`Personalization device activates EMV chip by sending
`reset Command
`
`/
`
`- - - - Y - 1 O 2
`EMV chip responds by sending Answer to Reset (ATR)
`
`y
`
`Select application to be personalized
`
`y
`
`1 O 3
`
`1 O 4.
`
`EMV chip returns the necessary file control nomation
`
`- 105
`y
`Initialization update command provides EMV chip with -1
`personalization device random number
`
`EMV chip sends sequence Counter, challenge, card
`cryptogram, identifier and version of session DES
`master key, deviation data, decryption and MAC DES
`keys, and a secure channel protocol identifier
`- Y - - -
`Personalization device authenticates itself to EMV chip
`by providing a cryptogram in the external authenticate
`Command
`
`106
`
`EMV chip confirms external authenticate
`
`-1 108
`
`109
`Personalization device begins shipping data to EMV /
`chip
`
`
`
`Confirmation of data storage
`
`cominator
`F.G. 1
`(Prior Art)
`
`-1
`
`110
`
`IPR2022-00412
`Apple EX1039 Page 2
`
`
`
`Patent Application Publication Sep. 7, 2006 Sheet 2 of 14
`30
`
`US 2006/0196931 A1
`
`24
`
`
`
`"Scaps
`
`Certificates
`
`
`
`
`
`40
`
`50
`
`FIG 2
`(Prior Art)
`
`IPR2022-00412
`Apple EX1039 Page 3
`
`
`
`Patent Application Publication Sep. 7, 2006 Sheet 3 of 14
`
`US 2006/0196931 A1
`
`
`
`FIG. 3
`(Prior Art)
`
`IPR2022-00412
`Apple EX1039 Page 4
`
`
`
`Patent Application Publication Sep. 7, 2006 Sheet 4 of 14
`
`US 2006/0196931 A1
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`40
`
`6O
`-1
`
`30
`
`l. Request (user
`identity)
`
`3, 40l Unauthorized
`WWW-Authenticate:
`Digest (RAND,
`AUTN delivered)
`
`2. Zh interface: BSF
`retrieves AV and user
`profile.
`-
`
`
`
`
`
`
`
`
`
`
`
`
`
`4. Client runs AKA
`algorithms, verifies
`AUTN, and derives
`session keys CK, IK
`and RES
`5. Request Authorization:
`Digest (RES used)
`
`
`
`
`
`
`
`
`
`
`
`6. Server check the
`given RES, if it is
`correct, 7.
`
`8. 200 OK
`B-TD, Key lifetime
`
`
`
`7. Ks=CKIIK
`
`
`
`9. Ks=CKIIK
`
`FIG. 4
`(Prior Art)
`
`IPR2022-00412
`Apple EX1039 Page 5
`
`
`
`Patent Application Publication Sep. 7, 2006 Sheet 5 of 14
`
`US 2006/0196931 A1
`
`
`
`
`
`Key derivation Ks->
`Ks NAF according to
`flag setting
`
`1. Application Request
`(B-TID, msg, MAC)
`
`B-TID, Ks, Prof
`
`2. Authentication Reques
`
`(B-TID, NAF hostname)
`< Authentication AnSWer
`(Ks NAF, Prof,
`Key lifetime)
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`The Server
`stores Ks NAF,
`Prof and Key lifetime
`4. Application Answer
`
`F.G. 5
`(Prior Art)
`
`IPR2022-00412
`Apple EX1039 Page 6
`
`
`
`Patent Application Publication Sep. 7, 2006 Sheet 6 of 14
`
`US 2006/0196931 A1
`
`OZ9
`
`
`
`
`
`
`
`?unoÐS
`
`?JOO
`
`JO ?ueuuÁed
`
`sÁey ?e loeS
`
`Z99
`
`#799
`
`IPR2022-00412
`Apple EX1039 Page 7
`
`
`
`Patent Application Publication Sep. 7, 2006 Sheet 7 of 14
`
`US 2006/0196931 A1
`
`UCC
`
`
`
`UE
`
`FIG. 7A
`
`IPR2022-00412
`Apple EX1039 Page 8
`
`
`
`Patent Application Publication Sep. 7, 2006 Sheet 8 of 14
`
`US 2006/0196931 A1
`
`
`
`Secure Core
`
`FIG. 7B
`
`IPR2022-00412
`Apple EX1039 Page 9
`
`
`
`Patent Application Publication Sep. 7, 2006 Sheet 9 of 14
`
`US 2006/0196931 A1
`
`801
`
`802
`
`803
`
`804
`
`User accesses Internet Banking Account and
`Selects to enable mobile device
`
`User enters phone number
`
`
`
`
`
`Financial institution receives request and
`agrees to enable mobile device
`
`Financial institution contacts a personalization
`bureau and transmits necessary user data
`
`FIG. 8
`
`IPR2022-00412
`Apple EX1039 Page 10
`
`
`
`Patent Application Publication Sep. 7, 2006 Sheet 10 of 14
`
`US 2006/0196931 A1
`901
`
`Financial server notifies NAF server to request
`that mobile device use GAA and the shared
`Secret method
`
`Shared secret is established between the UICC
`and the BSF server
`
`NAF server requests the shared secret from the
`BSF server
`
`UICC derives a new secret key that is given to
`the Secure Core
`
`
`
`
`
`
`
`902
`
`903
`
`904
`
`Secure core has secret key that can be used as
`a security issuer domain key
`
`
`
`905
`
`FIG. 9
`
`IPR2022-00412
`Apple EX1039 Page 11
`
`
`
`Patent Application Publication Sep. 7, 2006 Sheet 11 of 14
`
`US 2006/0196931 A1
`
`Secure tunnel established between SeCure COre
`and NAF Server
`
`
`
`Secure tunnel used to download security
`domain data to Secure Core
`
`Secure core establishes security domain for
`contactless payment application
`
`1 OO1
`
`1002
`
`/ 1OO3
`
`FIG 10
`
`IPR2022-00412
`Apple EX1039 Page 12
`
`
`
`Patent Application Publication Sep. 7, 2006 Sheet 12 of 14
`
`US 2006/0196931 A1
`
`1101
`
`1102
`
`1103
`
`1104
`
`1105
`
`1106 /
`
`1107
`
`User receives personalization Code on Web site
`
`
`
`
`
`
`
`NAF server pushes URL to user and instructs
`user to broWSe to that URL
`
`
`
`User browses to URL and is prompted to insert
`received personalization code into mobile
`device and send to NAF server
`
`NAF server pushes encrypted personalization
`tO Secure COre
`
`Mobile device personalizes secure Core and
`confirms correct initialization of the secure COre
`to the financial institution
`
`Terminal payment application downloaded and
`installed
`
`Secure core payment application downloaded
`and installed
`
`FIG 11
`
`IPR2022-00412
`Apple EX1039 Page 13
`
`
`
`Patent Application Publication
`
`Sep. 7, 2006 Sheet 13 of 14
`
`US 2006/0196931 A1
`
`
`
`
`
`z! '91
`
`[]
`
`G0/90
`
`
`
`QueuuÁed e??qoW
`
`
`
`suuu?? pueo
`
`
`
`IPR2022-00412
`Apple EX1039 Page 14
`
`
`
`Patent Application Publication Sep. 7, 2006 Sheet 14 of 14
`
`US 2006/0196931 A1
`
`
`
`Mobile Visa
`http:// mobilevisa.
`COm?id=1234567
`
`install Application
`
`Personalization
`COce
`
`Visa
`Aalto Anja
`
`OK
`
`Cancel
`
`Your Payment
`Application is
`installed
`successfully
`
`FIG. 14
`
`IPR2022-00412
`Apple EX1039 Page 15
`
`
`
`US 2006/0196931 A1
`
`Sep. 7, 2006
`
`METHODS, SYSTEM AND MOBILE DEVICE
`CAPABLE OF ENABLING CREDIT CARD
`PERSONALIZATION USING AWIRELESS
`NETWORK
`
`CROSS REFERENCE TO RELATED
`APPLICATION(S)
`0001. The present application claims priority from U.S.
`Provisional Application No. 60/659,258, filed Mar. 7, 2005
`entitled Methods, System and Mobile Device Capable of
`Enabling Credit Card Personalization Using a Wireless
`Network, the contents of which are incorporated herein in
`their entirety.
`
`FIELD OF THE INVENTION
`0002 This invention relates to enabling a mobile terminal
`for credit card personalization, and more particularly to
`enabling a mobile terminal for credit card personalization
`using a wireless network.
`
`BACKGROUND OF THE INVENTION
`0003 Credit card companies, such as MasterCard and
`Visa, are currently successfully using an EMV (Europay,
`MasterCard, and Visa) credit card payment standard to
`perform credit card personalization. Credit card personal
`ization refers to the process by which security and user data
`is transmitted to a user's credit card, such as a Smart card
`containing an EMV chip. A first step in this personalization
`process is establishing an issuer security domain, which
`today is typically done in the factory of a Smart card
`manufacturer. The security domain is used to create a secure
`channel between a personalization device, which is used to
`conduct the download of application data and the actual
`personalization, and the EMV chip embedded in the credit
`card. A secure channel is any channel over which informa
`tion can be transmitted without being readily publicly avail
`able, and may be created, for example, using various encryp
`tion schemes or by authenticating both end points of the
`channel. Once the secure channel is created, the personal
`ization device can activate the EMV chip and eventually
`transmit the personalization data to it. Credit card companies
`often rely on Smart card manufacturers, such as Orga,
`Axalto, Giesecke and Devrient, or Cedex, to perform this
`personalization process. These manufacturers receive the
`needed user personalization data from the credit card com
`panies and perform the steps discussed below in order to
`embed user-specific data into each credit card. The Smart
`card manufacturers can then act as credit card issuers on
`behalf of the credit card companies.
`0004 FIG. 1 is a flow chart illustrating the steps which
`may be taken, for example by a Smart card manufacturer,
`when performing credit card personalization today. In step
`101, the personalization device activates the EMV chip by
`sending it a reset command. The EMV chip responds, in step
`102, by sending an Answer to Reset (ATR) to the person
`alization device. The application that has to be personalized,
`for instance a specific credit card application which has been
`preloaded onto the card, is then selected using a select
`command, in step 103. In step 104, the EMV chip returns the
`necessary file control information, such as file data structure
`information, and in step 105 an initialize update command
`provides the EMV chip with a personalization device ran
`
`dom number. This random number is used as part of a
`cryptogram creation to establish a secure channel.
`0005 The chip responds, in step 106, by sending a
`sequence counter (for session key derivation), a challenge
`(to be used as part of the cryptogram creation), a card
`cryptogram (to be used to authenticate the chip), the iden
`tifier and version of the session DES (data encryption
`standard) master key, derivation data for encryption, decryp
`tion and message authentication code (MAC) DES (Data
`Encryption Standard) keys, and a source channel protocol
`identifier.
`0006.
`In step 107, the personalization device authenti
`cates itself to the EMV chip by providing a cryptogram in
`the external authentication command. The EMV chip then
`confirms the external authentication, in step 108, and then,
`in step 109, the personalization device starts shipping the
`data to the EMV chip by issuing one of several store data
`commands and eventually the special last store data. Finally,
`in step 110, the data storage is confirmed.
`0007 Recently, companies such as MasterCard and Visa
`have introduced a new payment method known, for
`example, as PayPass or Visa Waver, wherein credit cards are
`manufactured having RFID (radio frequency identification)
`capabilities. Under this new method, merchants are
`equipped with RFID devices that are capable of reading
`these RFID-capable credit cards when a user places his or
`her card a few centimeters in front of the reader. This new
`method enables faster and easier credit card payments.
`Similar proximity RFID systems are also being used in
`public transportation systems, such as Octopus or Helsinki
`Public Transport. For example, prepaid bus, or train, cards
`containing RFID capabilities may be purchased by custom
`ers and used in conjunction with RFID readers at the bus or
`train station to purchase tickets for riding the bus or train.
`0008. The use of RFID readers at different vendor loca
`tions, as well as at various public transportation stations,
`opens the door to other types of payment methods that could
`utilize these point-of-sale (POS)RFID readers. One such
`payment method would be to enable an individual to use his
`or her mobile phone, or some other mobile device, such as
`a personal digital assistant (PDA) or mobile personal com
`puter (PC) that is connected to a mobile phone or PDA (e.g.,
`via Bluetooth, cable, RFID, or Infrared), to transfer credit
`card or other user-specific information. In other words, the
`individual could use his or her mobile phone in the same
`circumstances as he or she would use his or her credit card
`or prepaid public transportation card. For example, the
`user's personal credit card details could be embedded in the
`mobile device and transmitted to the POS RFID reader. The
`same protocols used, for example, for PayPass and Visa
`Wave could be used. In this case, the mobile device would
`be connected to a PC; the PC would request the necessary
`data from the mobile device, and then transfer the data to the
`POS (via the Internet).
`0009. In order to implement this mobile EMV system, the
`overall system must first be certified. EMV certification is an
`expensive procedure defined by EMV that every smart card
`issuer that wishes to act as an EMV issuer must comply with.
`Without certification, it is unlikely that credit card compa
`nies will accept the inherent risks involved and “connect”
`the mobile EMV solution to their payment infrastructure.
`Mobile devices, however, are much more open than smart
`
`IPR2022-00412
`Apple EX1039 Page 16
`
`
`
`US 2006/0196931 A1
`
`Sep. 7, 2006
`
`cards, since they can run additional software applications
`and have more external interfaces than a Smart card. As a
`result, mobile EMV software applications built on existing
`mobile device hardware would likely face serious challenges
`when attempting to obtain EMV certification; thus making
`obtaining the requisite certification very difficult and expen
`S1V.
`0010. One alternative solution is to integrate an already
`certified EMV chip or smart card into the mobile device,
`rather than building mobile EMV software applications on
`existing mobile device hardware. To do this, one option is to
`introduce a second slot into the mobile device, wherein the
`EMV chip could be personalized as usual, for example at a
`Smart card manufacturer, and then later inserted into the
`mobile device by the user. However, this approach too can
`be very expensive due to the additional hardware costs for
`the mobile device for the mass-market. Other options would
`be to either incorporate a Universal Integrated Circuit Card
`(UICC) that supports many applications into the mobile
`device, or embed the certified EMV chip into the mobile
`device during manufacturing of the device.
`0011. During manufacturing, however, it is not known
`who will ultimately own each mobile device; thus prevent
`ing any payment data from being fully personalized during
`the normal manufacturing process. This is different from the
`credit card business of today, where the recipient of the card
`is known during issuance of the card. One solution is to
`incorporate the UICC or embed the certified EMV chip into
`the mobile device during manufacture and then require that
`the user send his or her mobile device to a smart card
`manufacturer or personalization bureau that can then per
`form the personalization, in a manner similar to that dis
`cussed above with respect to the credit cards. This, however,
`requires that the user relinquish his mobile device to the
`Smart card manufacturer for some period of time. Another
`Solution is to require that the user apply for a phone with
`credit card functionality in the same manner as he or she
`would apply for a credit card. The fully personalized mobile
`device having credit card capabilities would then be sent
`directly to the user. These options, however, would require
`that changes be made to the existing manufacturing process
`and sales channels, and they can be expensive and time
`consuming.
`0012 Another solution is to perform the personalization
`over the air (OTA) after the user has purchased his or her
`mobile device. However, certain risks are inherent in the
`transmission of security data OTA. As stated above, prior to
`initiating a personalization process, an issuer security
`domain that can be used to establish a secure channel
`between the personalization device and the EMV chip or
`UICC must be created. A need therefore exists for a secure
`means of transmitting credit card personalization data to a
`mobile device OTA i.e., a means of creating the requisite
`issuer security domain and secure channel.
`
`BRIEF SUMMARY OF THE INVENTION
`0013 Generally described, exemplary embodiments of
`the present invention provide an improvement over the
`known prior art by providing a method of creating an issuer
`security domain for the establishment of a secure channel
`over which personalization data, Such as credit card person
`alization or public transport ticketing data, can be transmit
`
`ted over the air (OTA). In particular, in exemplary embodi
`ments Generic Authentication Architecture (GAA) may be
`used to establish a shared secret that can be used to create a
`secure communication channel between the user equipment
`(UE) and a personalization application server or bureau
`acting as a network application function (NAF) server.
`0014.
`In general, as used herein, user equipment refers to
`a mobile device (e.g., a cellular telephone, personal digital
`assistant (PDA), laptop, pager, etc.) incorporating function
`ality to charge for goods or services requested for by the user
`of the user equipment. For example, user equipment may
`refer to a mobile device having EMV functionality through
`either an EMV-certified chip embedded in the mobile
`device, or one or more EMV applications stored on a UICC
`or Smart card associated with the mobile device. In one
`exemplary embodiment, the EMV application may be stored
`on the network operator's UICC or smart card. Alternatively,
`a separate, EMV-specific UICC or smart card containing the
`one or more EMV applications may be provided. In this
`embodiment, the mobile device would comprise two slots
`for the respective UICCs (i.e., the network operator UICC
`and the EMV-specific UICC), wherein the EMV-specific
`UICC or smart card is capable of being removed and used
`in conjunction with another mobile device also possessing
`two slots. In this way, a user is capable of using different
`mobile devices (e.g., the user's own, as well as his or her
`mothers, fathers, sister's, etc.) as a credit card or public
`transport ticketing card simply by inserting their EMV
`specific UICC or Smart card into the mobile device.
`0015 User equipment capable of receiving personaliza
`tion data over a secure channel, a personalization application
`server (e.g., a NAF server where GAA is used) capable of
`transmitting the personalization data over the secure chan
`nel, and a system embodying this user equipment and
`personalization application server, are also provided in
`exemplary embodiments.
`0016. According to one aspect of the invention, therefore,
`a method is provided for creating an issuer security domain
`that is capable of being used to establish a secure channel for
`over the air (OTA) transmission of personalization data from
`a personalization application server to an user equipment. In
`one exemplary embodiment, the method includes: (1) gen
`erating one or more shared secret keys known to the user
`equipment and the personalization application server; and
`(2) using the one or more shared secret keys to create an
`issuer security domain, wherein the issuer security domain
`is capable of being used to establish a secure channel for
`OTA transmission of personalization data from the person
`alization application server to the user equipment.
`0017 According to another aspect of the invention, a
`method of transmitting personalization data OTA from a first
`entity to a second entity in a secure manner is provided. In
`one exemplary embodiment, the method includes: (1) gen
`erating one or more shared secret keys known to the first and
`second entities using a Generic Authentication Architecture
`(GAA); (2) using the one or more shared secret keys to
`create an issuer security domain between the first and second
`entities; (3) establishing a secure channel between the first
`and second entities using the issuer security domain; and (4)
`transmitting the personalization data over the secure chan
`nel.
`0018. According to yet another aspect of the invention,
`an user equipment capable of receiving personalization data
`
`IPR2022-00412
`Apple EX1039 Page 17
`
`
`
`US 2006/0196931 A1
`
`Sep. 7, 2006
`
`from a personalization application server over a secure
`channel is provided. In one exemplary embodiment, the user
`equipment includes a user identification module comprising
`at least one secret key unique to the user equipment, and a
`secure core in communication with the user identification
`module. The secret key can be used to generate one or more
`shared secret keys known to the personalization application
`server and the user equipment that can be stored on the
`secure core. These shared secret keys can then be used to
`create an issuer security domain that can, in turn, be used to
`establish the secure channel over which the user equipment
`is capable of receiving the personalization data.
`0.019 According to another aspect of the invention, a
`mobile credit card payment system is provided. In one
`exemplary embodiment, the system includes a personaliza
`tion application server and an user equipment in communi
`cation with the personalization application server over a
`secure channel for transmitting personalization data OTA
`from the personalization application server to the user
`equipment. One or more shared secret keys known to the
`personalization application server and to the user equipment
`may be used to create an issuer security domain that, in turn,
`is capable of being used to establish the Secure channel.
`0020. According to yet another aspect of the invention, a
`system is provided for creating an issuer security domain
`that is capable of being used to establish a secure channel for
`OTA transmission of personalization data from a personal
`ization application server to an user equipment. In one
`exemplary embodiment, the system includes: (1) means for
`generating one or more shared secret keys known to the user
`equipment and the personalization application server, and
`(2) means for using the one or more shared secret keys to
`create an issuer security domain, wherein the issuer security
`domain is capable of being used to establish a secure channel
`for OTA transmission of personalization data from the
`personalization application server to the user equipment.
`0021 According to yet another aspect of the invention, a
`computer program product is provided for creating an issuer
`security domain that is capable of being used to establish a
`secure channel for OTA transmission of personalization data
`from a personalization application server to an user equip
`ment. In one exemplary embodiment, the computer program
`product comprises at least one computer-readable storage
`medium having computer-readable program code portions
`stored, therein. The computer-readable program code por
`tions may include: (1) a first executable portion for gener
`ating one or more shared secret keys known to the user
`equipment and the personalization application server, and
`(2) a second executable portion for using the one or more
`shared secret keys to create an issuer security domain,
`wherein the issuer security domain is capable of being used
`to establish a secure channel for OTA transmission of
`personalization data from the personalization application
`server to the user equipment.
`0022. According to another aspect of the invention, an
`user equipment capable of receiving personalization data
`from a personalization application server over a secure
`channel is provided. In one exemplary embodiment, the user
`equipment may include: (1) means for generating one or
`more shared secret keys known to the user equipment and
`the personalization application server; (2) means for storing
`the shared secret keys on the user equipment; and (3) means
`
`for using the shared secret keys to create an issuer security
`domain. The issuer security domain can be used to establish
`the secure channel over which the user equipment can
`receive the personalization data. In one exemplary embodi
`ment, the shared keys may be stored in a secure environment
`on the user equipment.
`0023. According to yet another aspect of the invention, a
`personalization application server capable of transmitting
`personalization data over a secure channel is provided. In
`one exemplary embodiment the personalization application
`server includes a processor and a memory in communication
`with the processor, wherein the memory stores an applica
`tion that is executable by the processor. In one exemplary
`embodiment, the application is capable, upon execution of
`receiving a request for security data and transmitting an
`authentication challenge in response to the request, wherein
`the challenge comprises a request that a shared secret key be
`used for authentication. The application may further be
`capable, upon execution, of receiving a response encrypted
`using the shared secret key, verifying the response, and upon
`verification, encrypting the security data requested using the
`shared secret key and transmitting the encrypted security
`data. The encrypted security data can then be used to create
`an issuer security domain capable of further being used to
`establish the secure channel. The application stored on the
`memory may further be capable, upon execution, of trans
`mitting the personalization data over the Secure channel
`established.
`0024. According to yet another aspect of the invention, a
`personalization application server capable of transmitting
`personalization data over a secure channel is provided. In
`one exemplary embodiment, the personalization application
`server includes: (1) means for receiving a request for Secu
`rity data; (2) means for transmitting an authentication chal
`lenge in response to the request, wherein the challenge
`comprises a request that a shared secret key be used for
`authentication; (3) means for receiving a response encrypted
`using the shared secret key; (4) means for verifying the
`response; (5) means for, upon verification, encrypting the
`security data requested using the shared secret key and
`transmitting the encrypted security data, wherein the
`encrypted security data is capable of being used to create an
`issuer security domain capable of being used to establish the
`secure channel; and (6) means for transmitting the person
`alization data over the secure channel.
`
`BRIEF DESCRIPTION OF THE SEVERAL
`VIEWS OF THE DRAWING(S)
`0025 Having thus described the invention in general
`terms, reference will now be made to the accompanying
`drawings, which are not necessarily drawn to scale, and
`wherein:
`0026 FIG. 1 is a flow chart illustrating prior art steps of
`performing a personalization of a credit card;
`0027 FIG. 2 illustrates an overview of a generic authen
`tication architecture environment according to the prior art;
`0028 FIG. 3 illustrates a network model for the generic
`bootstrapping according to the prior art;
`0029 FIG. 4 illustrates a generic bootstrapping proce
`dure according to the prior art;
`
`IPR2022-00412
`Apple EX1039 Page 18
`
`
`
`US 2006/0196931 A1
`
`Sep. 7, 2006
`
`0030 FIG. 5 illustrates a generic bootstrapping usage
`procedure according to the prior art;
`0031
`FIG. 6 is a block diagram of an user equipment
`capable of operating in accordance with exemplary embodi
`ments of the present invention;
`0032 FIGS. 7A and 7B are signal flow diagrams illus
`trating the steps taken when preparing an user equipment for
`credit card personalization according to exemplary embodi
`ments of the present invention;
`0033 FIGS. 8-11 are flow charts illustrating four phases
`for preparing an user equipment for credit card personaliza
`tion according to exemplary embodiments of the present
`invention;
`0034 FIGS. 12 and 13 illustrate exemplary web pages a
`user may see when selecting to enable his or her user
`equipment for credit card functionality according to exem
`plary embodiments of the present invention; and
`0035 FIG. 14 illustrates exemplary screens a user may
`See on his or her user equipment when enabling credit card
`functionality according to exemplary embodiments of the
`present invention.
`
`DETAILED DESCRIPTION OF THE
`INVENTION
`0036) The present inventions now will be described more
`fully hereinafter with reference to the accompanying draw
`ings, in which some, but not all embodiments of the inven
`tions are shown. Indeed, these inventions may be embodied
`in many different forms and should not be construed as
`limited to the embodiments set forth herein; rather, these
`embodiments are provided so that this disclosure will satisfy
`applicable legal requirements. Like numbers refer to like
`elements throughout.
`0037. In one exemplary embodiment, an issuer security
`domain that can be used to create a secure channel for
`transmitting personalization information, such as credit card
`personalization or public transport ticketing data, OTA to a
`mobile device is created. In an advantageous embodiment,
`this issuer security domain is established using a Generic
`Authentication Architecture (GAA). GAA is an authentica
`tion mechanism proposed by the third generation partnership
`project (3GPP) and described in the 3GPP Technical Speci
`fication33.919, entitled Generic Authentication Architecture
`(GAA); System Description (Release 6, March 2005) (3GPP
`TS 33.919 v6.2.0 (2005-03)), the contents of which are
`incorporated herein by reference in their entirety. GAA is
`intended to be used as a security procedure for various
`applications and services for users of mobile devices, such
`as mobile phones, personal digital assistants (PDAs), or
`mobile PCs (personal computers), or the like.
`GAA and General Bootstrapping Procedures:
`0038 GAA is based on shared secret keys that are stored
`on specific secure storage entities provided in association
`with the user equipment (UE), as well as in subscriber
`databases in a mobile operator network. The secure storage
`entity of the UE may be provided by an appropriate security
`module or identification module, such as a Subscriber Iden
`tity Module (SIM) or a Universal Integrated Circuit Card
`(UICC) containing a SIM-like application, for example
`Universal SIM (USIM). The subscriber database may be
`
`provided by a network entity Such as a Home Location
`Register (HLR) or Home Subscriber Server (HSS). The
`secure user identity storage entities and the Subscriber
`database entities are typically controlled by mobile network
`operators who issue the user identities and who typically run
`and own the Subscriber databases. An operator may, for
`example, in an application of GAA relating to mobile
`devices, be the mobile device user's service provider (e.g.,
`T-Mobile or Sprint). Under GAA, the HSS or HRL and the
`secure storage entity of the UE have a common shared secret
`that is given to the HSS/HRL and secure storage entity by
`the mobile network operator, and is used for authenticating
`the user and the mobile network. This operator-owned
`shared secret is then used by GAA to derive new application
`specific shared keys.
`0.039
`FIG. 2 is an overview of a GAA environment 20 in
`interrelation with the Home Subscriber Server (HSS)30, the
`User Equipment (UE) 40, and a Network Entity (NE) 50.
`GAA 20 basically consists of a Generic Bootstrapping
`Architecture (GBA) 22, subscriber certificates 24, and an
`Authentication Proxy (AP) 26. An exemplary use of GAA 20
`would be to provide credentials (e.g., shared secrets) to a
`mobil