USOO7628322B2
`
`(12) United States Patent
`Holtmanns et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 7.628,322 B2
`Dec. 8, 2009
`
`(54) METHODS, SYSTEMAND MOBILE DEVICE
`CAPABLE OF ENABLING CREDIT CARD
`PERSONALIZATION USING AWIRELESS
`NETWORK
`
`7,023,994 B1* 4/2006 Dupre ........................ 380.247
`2002fO164031 A1* 11, 2002 Pikivi ...........
`... 380,270
`2004O168063 A1* 8/2004 Revital et al. .....
`... 713,172
`2006/0265595 A1* 11/2006 Scottodiluzio .............. T13, 18O
`
`
`
`(75) Inventors: Silke Holtmanns, Vantaa (FI); Pekka
`Laitinen, Helsinki (FI)
`s
`(73) Assignee: Nokia Corporation, Espoo (FI)
`(*) Notice:
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 686 days
`M
`YW-
`(21) Appl. No.: 11/237,811
`
`y x- - -
`
`9
`
`(22) Filed:
`(65)
`
`Sep. 28, 2005
`Prior Publication Data
`
`FOREIGN PATENT DOCUMENTS
`
`DE
`EP
`
`10 2005 O25 684 A1
`8, 2006
`1408 669 A1
`4/2004
`OTHER PUBLICATIONS
`3GPP TR 33.919, 3 Generation Partnership Project; Technical
`Specification Group Services and System Aspects; 3G Security;
`Generic Authentication Architecture (GAA); System Description
`(Release 6), Technical Report, Mar. 2005, Version 6.2.0, pp. 1-13,3'
`Generation Partnership Project.
`(Continued)
`Primary Examiner Daniel A Hess
`(74) Attorney, Agent, or Firm—Alston & Bird LLP
`
`Related U.S. Application Data
`(60) Provisional application No. 60/659,258, filed on Mar.
`7, 2005.
`
`(51) Int. Cl.
`(2006.01)
`H04LK LM00
`(52) U.S. Cl. ....................................... 235/380; 380/247
`(58) Field of Classification Search ................. 235/380,
`380/247; 455/411; 713/168
`See application file for complete search history.
`References Cited
`U.S. PATENT DOCUMENTS
`
`(56)
`
`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 Architecture
`(GAA) may be used to establish a secure communication
`channel between the user equipment (UE) and a personaliza
`tion application server or bureau acting as a network applica
`tion function (NAF) server. An user equipment, personaliza
`tion 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 pro
`vided for creating a secure channel, such as via GAA, over
`which credit card personalization data can be transmitted
`OTA
`
`5,557,679 A
`
`9, 1996 Julin et al.
`
`47 Claims, 14 Drawing Sheets
`
`| 610
`
`620
`
`Secure
`Core
`Generated
`Shared
`Secret Keys
`
`Payment or
`Ticketing
`Application
`
`612
`
`614
`
`UICC
`
`EMV U
`
`G BA U
`
`ldentification
`information
`
`622
`
`624
`
`626
`
`632
`
`634
`
`EMV
`
`GBA
`
`GOOG-1006
`GOOGLE LLC v. RFCYBER CORP. / Page 1 of 27
`
`

`

`US 7.628,322 B2
`Page 2
`
`OTHER PUBLICATIONS
`Niemi et al., Network Working Group Request for Comment: 3310,
`Hypertext Transfer Protocol (HTTP) Digest Authentication Using
`Authentication and Key Agreement (AKA), Technical Specification,
`Retrieved Aug. 4, 2005 from Internet Site ftp://ftp.rfe-editor.org/in
`notes/rfc3310.txt, pp. 1-17.
`3GPP TS 33.220, 3 Generation Partnership Project: Technical
`Specification Group Services and System Aspects; Generic Authen
`tication Architecture (GAA); Generic Bootstrapping Architecture
`(Release 7), Technical Specification, Jun. 2005, Version 7.0.0, pp.
`
`1-41, 3" Generation Partnership Project.
`Calhoun et al., Network Working Group Request for Comment:
`3588, Diameter Base Protocol, Technical Specification, Retrieved
`Aug. 4, 2005 from Internet Site http://www.ietforg/rfc/rfc3588.txt,
`pp. 1-138.
`Global Platform, Card Specification, Technical Specification, Mar.
`2003, pp. 1-237. Version 2.1.1, Global Platform, Inc., USA.
`International Search Report for PCT/IB2006/000412 dated Aug. 29,
`2006.
`* cited by examiner
`
`GOOG-1006
`GOOGLE LLC v. RFCYBER CORP. / Page 2 of 27
`
`

`

`U.S. Patent
`
`Dec. 8, 2009
`
`Sheet 1 of 14
`
`US 7.628,322 B2
`
`101
`- - -
`- - - -
`Personalization device activates EMV chip by sending /
`reset command
`
`- - Y - - 102
`
`EMV chip responds by sending Answer to Reset (ATR)
`
`y
`
`Select application to be personalized
`
`-1 103
`
`EMV chip returns the necessary file control nomalion
`
`/ 104
`
`105
`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
`
`/
`Personatalongeviseausalesee Eyebel/"
`
`Personalization device authenticates itself to EMV chip
`by providing a cryptogram in the external authenticate
`Command
`
`EMV chip confirms external authenticate
`
`-1 108
`
`109
`Personalization device begins shipping data to EMW /
`chip
`
`Confirmation of data storage
`
`110
`
`F.G. 1
`(Prior Art)
`
`GOOG-1006
`GOOGLE LLC v. RFCYBER CORP. / Page 3 of 27
`
`

`

`U.S. Patent
`
`Dec. 8, 2009
`
`Sheet 2 of 14
`
`US 7.628,322 B2
`
`
`
`30
`
`Certificates
`
`FIG 2
`(Prior Art)
`
`GOOG-1006
`GOOGLE LLC v. RFCYBER CORP. / Page 4 of 27
`
`

`

`U.S. Patent
`
`Dec. 8, 2009
`
`Sheet 3 of 14
`
`US 7.628,322 B2
`
`
`
`30
`
`FIG. 3
`(Prior Art)
`
`GOOG-1006
`GOOGLE LLC v. RFCYBER CORP. / Page 5 of 27
`
`

`

`U.S. Patent
`
`Dec. 8, 2009
`
`Sheet 4 of 14
`
`US 7.628,322 B2
`
`3O
`
`Gass)
`
`2. Zh interface: BSF
`retrieves AV and user
`profile.
`-
`
`40
`-1 60
`(E) l. Request (user Ges)
`
`identity)
`
`3. 40l Unauthorized
`WWW-Authenticate:
`Digest (RAND,
`AUTN delivered)
`
`
`
`
`
`
`
`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=CKIK
`
`9. Ks=CKIIK
`
`F.G. 4
`(Prior Art)
`
`GOOG-1006
`GOOGLE LLC v. RFCYBER CORP. / Page 6 of 27
`
`

`

`U.S. Patent
`
`Dec. 8, 2009
`
`Sheet 5 of 14
`
`US 7.628,322 B2
`
`
`
`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)
`3. Authentication AnSWer
`(Ks NAF, Prof,
`Key lifetime)
`
`
`
`The Server
`stores Ks NAF,
`Prof and Key lifetime
`4. Application Answer
`
`F.G. 5
`(Prior Art)
`
`GOOG-1006
`GOOGLE LLC v. RFCYBER CORP. / Page 7 of 27
`
`

`

`U.S. Patent
`
`Dec. 8, 2009
`
`Sheet 6 of 14
`
`US 7.628,322 B2
`
`OZ9
`
`
`
`–—,
`
`/\WE
`
`GOOG-1006
`GOOGLE LLC v. RFCYBER CORP. / Page 8 of 27
`
`

`

`U.S. Patent
`
`Dec. 8, 2009
`
`Sheet 7 of 14
`
`US 7.628,322 B2
`
`
`
`FIG. 7A
`
`GOOG-1006
`GOOGLE LLC v. RFCYBER CORP. / Page 9 of 27
`
`

`

`U.S. Patent
`
`Dec. 8, 2009
`
`Sheet 8 of 14
`
`US 7.628,322 B2
`
`
`
`Secure Core
`
`FIG 7B
`
`GOOG-1006
`GOOGLE LLC v. RFCYBER CORP. / Page 10 of 27
`
`

`

`U.S. Patent
`
`Dec. 8, 2009
`
`Sheet 9 of 14
`
`US 7.628,322 B2
`
`User accesses Internet Banking ACCount and
`Selects to enable mobile device
`
`801
`
`8O2
`
`
`
`
`
`
`
`
`
`User enters phone number
`
`803
`Financial institution receives request and /
`agrees to enable mobile device
`
`Financial institution contacts a personalization
`bureau and transmits necessary user data
`
`804
`
`FIG. 8
`
`GOOG-1006
`GOOGLE LLC v. RFCYBER CORP. / Page 11 of 27
`
`

`

`U.S. Patent
`
`Dec. 8, 2009
`
`Sheet 10 of 14
`
`US 7.628,322 B2
`
`901
`
`902
`
`903
`
`904
`
`905
`
`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
`
`Secure core has secret key that can be used as
`a security issuer domain key
`
`FIG. 9
`
`GOOG-1006
`GOOGLE LLC v. RFCYBER CORP. / Page 12 of 27
`
`

`

`U.S. Patent
`
`Dec. 8, 2009
`
`Sheet 11 of 14
`
`US 7.628,322 B2
`
`
`
`Secure tunnel established between Secure COre
`and NAF server
`
`—-y-
`Secure tunnel used to download security
`domain data to secure Core
`
`Secure Core establishes security domain for
`contactless payment application
`
`1 OO1
`
`10O2
`
`- 1003
`
`FIG 10
`
`GOOG-1006
`GOOGLE LLC v. RFCYBER CORP. / Page 13 of 27
`
`

`

`U.S. Patent
`
`Dec. 8, 2009
`
`Sheet 12 of 14
`
`US 7.628,322 B2
`
`
`
`
`
`
`
`
`
`
`
`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
`
`11 O1
`
`1102
`
`1103
`
`1 104
`
`1105
`
`1106
`
`11 O7
`
`GOOG-1006
`GOOGLE LLC v. RFCYBER CORP. / Page 14 of 27
`
`

`

`U.S. Patent
`
`US 7.628,322 B2
`
`
`
`< ?SOJO >
`
`
`
`
`
`
`
`GOOG-1006
`GOOGLE LLC v. RFCYBER CORP. / Page 15 of 27
`
`

`

`U.S. Patent
`
`Dec. 8, 2009
`
`Sheet 14 of 14
`
`US 7.628,322 B2
`
`
`
`Service Message
`
`Mobile Visa
`http:// mobilevisa
`Com?id=1234567
`
`install Application
`
`Your Payment
`Application is
`installed
`SuCCessfully
`
`FIG. 14
`
`GOOG-1006
`GOOGLE LLC v. RFCYBER CORP. / Page 16 of 27
`
`

`

`US 7.628,322 B2
`
`1.
`METHODS, SYSTEMAND MOBILE DEVICE
`CAPABLE OF ENABLING CREDIT CARD
`PERSONALIZATION USING AWIRELESS
`NETWORK
`
`CROSS REFERENCE TO RELATED
`APPLICATION(S)
`The present application claims priority from U.S. Provi
`sional 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
`
`10
`
`15
`
`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
`
`2
`part of the cryptogram creation), a card cryptogram (to be
`used to authenticate the chip), the identifier and version of the
`session DES (data encryption standard) master key, deriva
`tion data for encryption, decryption and message authentica
`tion code (MAC) DES (Data Encryption Standard) keys, and
`a source channel protocol identifier.
`In step 107, the personalization device authenticates 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.
`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 manufac
`tured having RFID (radio frequency identification) capabili
`ties. 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 centime
`ters 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 pur
`chased by customers and used in conjunction with RFID
`readers at the bus or train station to purchase tickets for riding
`the bus or train.
`The use of RFID readers at different vendor locations, 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 per
`Sonal digital assistant (PDA) or mobile personal computer
`(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).
`In order to implement this mobile EMV system, the overall
`system must first be certified. EMV certification is an expen
`sive procedure defined by EMV that every smart card issuer
`that wishes to act as an EMV issuer must comply with. With
`out certification, it is unlikely that credit card companies will
`accept the inherent risks involved and “connect the mobile
`EMV solution to their payment infrastructure. Mobile
`devices, however, are much more open than Smartcards, since
`they can run additional Software applications and have more
`external interfaces thana Smartcard. As a result, mobile EMV
`Software applications built on existing mobile device hard
`ware would likely face serious challenges when attempting to
`obtain EMV certification; thus making obtaining the requisite
`certification very difficult and expensive.
`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
`
`25
`
`35
`
`40
`
`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 personalization refers to the pro
`cess 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
`30
`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 information can be transmitted without being
`readily publicly available, and may be created, for example,
`using various encryption schemes or by authenticating both
`end points of the channel. Once the secure channel is created,
`the personalization 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
`45
`needed user personalization data from the credit card compa
`nies and perform the steps discussed below in order to embed
`user-specific data into each credit card. The Smart card manu
`facturers can then act as credit card issuers on behalf of the
`credit card companies.
`FIG. 1 is a flow chart illustrating the steps which may be
`taken, for example by a Smart card manufacturer, when per
`forming 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 personalization
`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 com
`mand, in step 103. In step 104, the EMV chip returns the
`60
`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 random
`number. This random number is used as part of a cryptogram
`creation to establish a secure channel.
`The chip responds, in step 106, by sending a sequence
`counter (for session key derivation), a challenge (to be used as
`
`50
`
`55
`
`65
`
`GOOG-1006
`GOOGLE LLC v. RFCYBER CORP. / Page 17 of 27
`
`

`

`US 7.628,322 B2
`
`10
`
`15
`
`25
`
`30
`
`35
`
`3
`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 incorpo
`rate a Universal Integrated Circuit Card (UICC) that supports
`many applications into the mobile device, or embed the cer
`tified EMV chip into the mobile device during manufacturing
`of the device.
`During manufacturing, however, it is not known who will
`ultimately own each mobile device; thus preventing any pay
`ment 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
`UICCorembed 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 personal
`ization bureau that can then perform the personalization, in a
`manner similar to that discussed 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, how
`ever, would require that changes be made to the existing
`manufacturing process and sales channels, and they can be
`expensive and time consuming.
`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 transmis
`sion 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 personal
`ization 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.
`
`40
`
`BRIEF SUMMARY OF THE INVENTION
`
`50
`
`Generally described, exemplary embodiments of the
`45
`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 personalization or
`public transport ticketing data, can be transmitted over the air
`(OTA). In particular, in exemplary embodiments Generic
`Authentication Architecture (GAA) may be used to establish
`a shared secret that can be used to create a secure communi
`cation channel between the user equipment (UE) and a per
`Sonalization application server or bureau acting as a network
`application function (NAF) server.
`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 smartcard. Alternatively, a sepa
`
`55
`
`60
`
`65
`
`4
`rate, EMV-specific UICC or smart card containing the one or
`more EMV applications may be provided. In this embodi
`ment, 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 conjunc
`tion 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,
`sisters, etc.) as a credit card or public transport ticketing card
`simply by inserting their EMV-specific UICC or smart card
`into the mobile device.
`User equipment capable of receiving personalization data
`over a secure channel, a personalization application server
`(e.g., a NAF server where GAA is used) capable of transmit
`ting the personalization data over the Secure channel, and a
`system embodying this user equipment and personalization
`application server, are also provided in exemplary embodi
`mentS.
`According to one aspect of the invention, therefore, a
`method is provided for creating an issuersecurity 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) gener
`ating one or more shared secret keys known to the user equip
`ment 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 personalization application
`server to the user equipment.
`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 exem
`plary embodiment, the method includes: (1) generating 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 issuersecurity domain; and (4) transmitting
`the personalization data over the secure channel.
`According to yet 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
`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 issuersecurity
`domain that can, in turn, be used to establish the secure
`channel over which the user equipment is capable of receiv
`ing the personalization data.
`According to another aspect of the invention, a mobile
`credit card payment system is provided. In one exemplary
`embodiment, the system includes a personalization applica
`tion server and an user equipment in communication with the
`personalization application server over a secure channel for
`transmitting personalization data OTA from the personaliza
`tion application server to the user equipment. One or more
`shared secret keys known to the personalization application
`
`GOOG-1006
`GOOGLE LLC v. RFCYBER CORP. / Page 18 of 27
`
`

`

`5
`server and to the user equipment may be used to create an
`issuersecurity domain that, in turn, is capable of being used to
`establish the secure channel.
`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 personalization
`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
`15
`transmission of personalization data from the personalization
`application server to the user equipment.
`According to yet another aspect of the invention, a com
`puter program product is provided for creating an issuersecu
`rity 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 equipment. 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 portions may
`include: (1) a first executable portion for generating one or
`more shared secret keys known to the user equipment and the
`personalization application server, and (2) a second execut
`able 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 per
`Sonalization application server to the user equipment.
`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 personaliza
`tion 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 per
`Sonalization data. In one exemplary embodiment, the shared
`keys may be stored in a secure environment on the user
`equipment.
`According to yet another aspect of the invention, a person
`alization application server capable of transmitting personal
`50
`ization data over a secure channel is provided. In one exem
`plary embodiment the personalization application server
`includes a processor and a memory in communication with
`the processor, wherein the memory stores an application that
`is executable by the processor. In one exemplary embodi
`ment, 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
`
`6
`further be capable, upon execution, of transmitting the per
`Sonalization data over the secure channel established.
`According to yet another aspect of the invention, a person
`alization application server capable of transmitting personal
`ization data over a secure channel is provided. In one exem
`plary embodiment, the personalization application server
`includes: (1) means for receiving a request for security data;
`(2) means for transmitting an authentication challenge 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 personalization data over the secure channel.
`
`BRIEF DESCRIPTION OF THE SEVERAL
`VIEWS OF THE DRAWING(S)
`
`Having thus described the invention in general terms, ref
`erence will now be made to the accompanying drawings,
`which are not necessarily drawn to scale, and wherein:
`FIG. 1 is a flow chart illustrating prior art steps of perform
`ing a personalization of a credit card;
`FIG. 2 illustrates an overview of a generic authentication
`architecture environment according to the prior art;
`FIG. 3 illustrates a network model for the generic boot
`strapping according to the prior art;
`FIG. 4 illustrates a generic bootstrapping procedure
`according to the prior art;
`FIG. 5 illustrates a generic bootstrapping usage procedure
`according to the prior art;
`FIG. 6 is a block diagram of an user equipment capable of
`operating in accordance with exemplary embodiments of the
`present invention;
`FIGS. 7A and 7B are signal flow diagrams illustrating the
`steps taken when preparing an user equipment for credit card
`personalization according to exemplary embodiments of the
`present invention;
`FIGS. 8-11 are flow charts illustrating four phases for
`preparing an user equipment for credit card personalization
`according to exemplary embodiments of the present inven
`tion;
`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 exemplary embodi
`ments of the present invention; and
`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 inven
`tion.
`
`DETAILED DESCRIPTION OF THE INVENTION
`
`The present inventions now will be described more fully
`hereinafter with reference to the accompanying drawings, in
`which some, but not all embodiments of the inventions 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 through
`Out.
`
`US 7.628,322 B2
`
`10
`
`25
`
`30
`
`35
`
`40
`
`45
`
`55
`
`60
`
`65
`
`GOOG-1006
`GOOGLE LLC v. RFCYBER CORP. / Page 19 of 27
`
`

`

`US 7.628,322 B2
`
`7
`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 personaliza
`tion or public transport ticketing data, OTA to a mobile device
`is created. In an advantageous embodiment, this issuer Secu
`rity domain is established using a Generic Authentication
`Architecture (GAA). GAA is an authentication mechanism
`proposed by the third generation partnership project (3GPP)
`and described in the 3GPP Technical Specification 33.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