USOO8601266B2
`
`(12) United States Patent
`(10) Patent N0.:
`US 8,601,266 B2
`
`Aabye et al.
`(45) Date of Patent:
`Dec. 3, 2013
`
`(54) MUTUAL MOBILE AUTHENTICATION
`USING A KEY IVIANAGEMENT CENTER
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`(75)
`
`Inventors: Christian Aabye, Foster City, CA (US);
`Sasikumar Kannappan. Foster City,
`CA (US)
`
`(73) Assignee: Visa International Service Association,
`San Francisco, CA (US)
`
`.................. 705/66
`9/1998 Cuny et a1.
`5,805,702 A *
`6,327,578 B1 '“" 12/2001 Linehan .......................... 705/65
`7,3 89,531 B2
`6/2008 Fransdonk
`2009/0119504 A1"<
`5/2009 van Os et a1.
`................. 713/153
`2010/0211507 A1
`8/2010 Aabye et a1.
`
`FOREIGN PATENT DOCUMENTS
`
`( * ) Notice:
`
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 60 days.
`
`KR
`
`11/2005
`10-2005-0103681 A
`OTHER PUBLICATIONS
`
`(21) App1.No.: 13/075,592
`
`(22)
`
`Filed:
`
`Mar. 30, 2011
`
`(65)
`
`Prior Publication Data
`US 2011/0247063 A1
`Oct. 6. 2011
`
`Related U.S. Application Data
`
`(60) Provisional application No. 61/319698, filed on Mar.
`31, 2010.
`
`(51)
`
`Int. Cl.
`H04L 29/06
`
`(2006.01)
`
`(52) U.S. Cl.
`USPC ........................................... 713/168; 380/279
`(58) Field of Classification Search
`USPC .......... 713/153, 168, 170, 380/277, 278, 279,
`380/286; 705/61, 65, 66
`See application file for complete search history.
`
`Sankar. K.. et 31., "Cisco Wireless LAN Security.” Cisco Press. 2004.
`ISBN 1—58705-154-0. pp. 157—192.
`Menezes. A.. et a1, “Handbook of Applied Cryptography,” CRC
`Press, 1996, pp. 36-37, 546-547 and figs 1.16 and 13.1.
`PCT Search RepOIt and Written Opinion, PCT/US2011/030766,
`mailcd Nov. 8, 2011, 11 pages.
`
`* cited by examiner
`
`
`Primary Examiner 7 Edward Zee
`(74) Attorney, Agent, or Firm
`Stockton LLP
`
`Kilpatrick Townsend &
`
`ABSTRACT
`(57)
`A system, method, and server computer configured to authen—
`ticate a consumer device. The consumer device is authenti—
`cated via a mobile gateway using challenge—response authen—
`tication. Ifthe consumer device is successfully authenticated,
`a secure channel is established between the consumer device
`and a first entity. The secure channel allows for secure com-
`munication between the consumer device and the first entity.
`
`21 Claims, 9 Drawing Sheets
`
`CONSUMER
`DEVICE
`
`CHALLENGE REQUEST
`
`MESSAGE
`S502
`CHALLENGE MESSAGE
`S504
`
`CHALLENGE RESPONSE
`MESSAGE S506
`
`MOBILE
`
`GATEWAY
`
`AUTHENTICATION WEB
`SERVICE REQUEST
`S508
`
`' —AU1'EIENTTCATII(—3N—W—EIB—I
`SERVICE RESPONSE
`8510
`
`150
`
`
`
`I:;ILHL:I__
`Rafi
`
`SECURE CHANNEL
`RESPONSE MESSAGE S512
`
`LEGEND:
`—> TCP SOCKET INTERACTION
`
`— ------- + WEB SERVICE INTERACTION
`
`Google LLC v. RFCyber Corp. / Page 1 of 20
`
`GOOG-1033
`
`GOOG-1033
`Google LLC v. RFCyber Corp. / Page 1 of 20
`
`PGR2022-00003
`Apple EX1033 Page 1
`
`

`

`US. Patent
`
`c.
`
`9f0
`
`6900S
`
`2B6
`
`m|zo_5<mz<EN:we
`._.Zm__>_><n_
`éogmzENE/Emom
`
`
`
`
`
`Oz_wmm_oomn_
`
`wwmfiofizoo
`
`
`
`
`
`
`mow
`
`
`
`
`
`3EMEE‘mzo_EN_mo_._5<6\Q3,EmEEmeBEZBu,.
`
`
`
`U><>>E<o£502
`
`%Im,Por.
`
`may2852
`
`a828%w895%g/EEES
`
`63%Bio:
`
`33maooG
`o2fO2e9aPla.rOCrebV.CFRv.CLLb9OOG
`
`‘
`
`ézémfl
`
`GOOG-1033
`Google LLC v. RFCyber Corp. / Page 2 of 20
`
`PGR2022-00003
`Apple EX1033 Page 2
`
`

`

`US. Patent
`
`Dec. 3, 2013
`
`Sheet 2 0f 9
`
`US 8,601,266 B2
`
`w:
`
`<._.O
`
`
`
`OHWOwR/WWHQmmmAHO/NFZOOE;HZm—_>;<n_
`._.Zm__>_><n_w<Qmwwmoomn—
`aQN.9”.
`
`
`
`._<z__>_mm_._.wn_0>
`
`cor
`
`/$295$3382
`><>>m_._.<0m_.__mO_>_fiflfl
`
`vfium
`
`
`
`
`
`FEE:mmzamzo:<>_5<..-8%.;288.;
`
`
`
`$stimmsomm”.55me85:5CE:0&5“?
`
`
`zo_EN:<zome.gmbmmo/‘zé£0
`
` /@_=20.2%2592:
`
`\g.2098%‘.8%3m..
`
`mmzmgn1.2%._.m_mn_z<_._
`
`zo_.—<§~..__n_zoo
`
`<29.
`
`'
`
`mowm
`
`%‘
`
`{£2
`
`#3
`
`55%OHmm?\mmmm_n__>omn_
`
`m..__m_o_>_
`
`zO_._.<o_._n_n_<
`
`
`
`
`
`
`
`
`
`
`
`
`
`33maooG
`o2fO3e9aPla.rOCrebV.CFRv.CLLb9OOG
`
`GOOG-1033
`Google LLC v. RFCyber Corp. / Page 3 of 20
`
`PGR2022-00003
`Apple EX1033 Page 3
`
`

`

`US. Patent
`
`Dec. 3, 2013
`
`Sheet 3 0f9
`
`US 8,601,266 B2
`
`
`GPRS
`
`
`4/
`
`TCP OVER WIFI
`
`TCP OVER
`
`132
`
`MOBILE NETWORK
`
`OPERATOR (MNO)
`
`FIG. 3
`
`MOBILE GATEWAY
`
`104(gl
`
`Computer
`Readable
`Medium
`
`1041b)
`
`In
`put
`Elements
`
`195m
`
`Contactless
`Element
`
`Processor
`1(l4(g)
`
`104(h)
`
` GOOG-1033
`
`Google LLC v. RFCyber Corp. / Page 4 of 20
`
`GOOG-1033
`Google LLC v. RFCyber Corp. / Page 4 of 20
`
`PGR2022-00003
`Apple EX1033 Page 4
`
`

`

`US. Patent
`
`Dec. 3, 2013
`
`Sheet 4 0f 9
`
`US 8,601,266 B2
`
`m2
`
`m_.__m_O_>_
`
`><>>m_._.<o
`
`
`
`zO_._.<>_._.o<_>_m_u_zoo
`
`
`
`
`
`HmmzomEzO_._.<>_._.o<szmN
`
`_>_m_._.m>m
`
`m.0."—
`
`
`
`
`
`man?<n=>_>w<_>_>zo_m_>Ow_n_
`
`
`
`
`
`mo_>m_omm=>5mzoo
`
`33maooG
`02fo5e9aPla.roCrebV.CFRv.CLLb9ooG
`
`mmawg
`
`
`
`v:Fzm_>_><n_
`
`
`
`
`
`m_.__m_O_>_>._.__>__xomn_mon—MEQOMK
`
`mmzsmzoo
`
`N9
`
`
`
`
`
`
`
`
`GOOG-1033
`Google LLC v. RFCyber Corp. / Page 5 of 20
`
`PGR2022-00003
`Apple EX1033 Page 5
`
`

`

`US. Patent
`
`C.
`
`9f0
`
`698S
`
`2B6%
`
`52%m_.m_m.>.>.z_e%EmEpfi”mmzmmammowm
`
`
`55%28%H58:05mg?
`B.I.I.I.I.m%Im.IIIIIIII
`Uzocoéflz55%mm;4.......I
`
`m38
`3,mm;zo:<o:zm:5<mszmmmmmozflézo
`
`
`
`'0 mo_>m_n_
`Zeb/EH;558m8A|
`
`
`
`><>>E<omomw
`
`mm?
`
`
`
`350:mega:
`
`
`
`:32?$25.25
`
`
`
`mo<mmm=2mozm._._<Io
`
`S:
`
`mmEDszo
`
`0
`
`WHO
`
`m,m0_n—
`
`”gzmomJ
`
`33maooG
`02fo6e9aPla.roCrebV.CFRv.CLLb9ooG
`
`
`
`
`
`
`
`
`
`GOOG-1033
`Google LLC v. RFCyber Corp. / Page 6 of 20
`
`PGR2022-00003
`Apple EX1033 Page 6
`
`

`

`US. Patent
`
`3,
`
`9
`
`068,S
`
`2now
`
`
`
`
`
`0522EE,><>>E<e£5925&8:panamamozfiézoE23248
`
`
`
`
`
`
`
`Nam55%
`
`
`
`m38DH382mozmj/Eo
`
`
`
`
`
`388m$582mmzolmmmmezmjsé
`
`n,h6.”.
`
`
`
`UZOE/E2550m18A|
`
`”ozmomJ
`
`M2,288mEgo:mo<mmmzmmzommmmfizz/«Io
`
`
`
`mmsommME.I.%thr_Wh=I=__,flu.SL
`
`hmnuoonu
`
`nwroCrekuv.CErRmCILIL
`
`/
`
`33maooG
`09.fo7ea.aD.
`
`Fm?var
`
`
`
`
`
`
`
`GOOG-1033
`Google LLC v. RFCyber Corp. / Page 7 of 20
`
`PGR2022-00003
`Apple EX1033 Page 7
`
`

`

`US. Patent
`
`9f
`
`2B
`
`3,8amasD20:82on
`caocx20:82on
`
`5:85O8%3g
`
`5%
`
` E20:82onEOE/2m
`
`5:85002658294;
`
`228228as52H
`
`3%
`
`oomm
`
`$15
`
`9mm
`
`83.382O5255::5%
`
`18$20
`
`
`.m228228
`E2EEOEzBEE
`
`t$385w29QO%5933me52:38:02
`
`zo_wmm_m
`
`EmBmesa;mgE56%
`
`N
`
`mmmm
`
`E38823%
`
`Efififlo
`
`
`EEO2%
`
`mm
`
`2%
`
`
`zo_mmm_mx810
`:02:028mm
`
`20EmmrEzmQ
`
`mmod>zm
`
`napmmod
`
`in:mmod
`
`20:82on
`
`zgwwmmmoz@255Oz
`8,mam
`
`
`3%EE9%E6%
`92E2mmodzoimmm0E1573:m>E<
`
`3a
`
`zo_mmm_m02
`
`
`
`
`
`0255$10.2:zocomzzoo
`
`
`
`mo;zogmzzoo
`
`298mm92
`
`
`
` 8%Ozzocbmzzoo
`
`lg$2$90
`
`NNNm
`
`
`
`mopm>_5<mm;vmmm
`
`%zoammm
`
`2,02E:M85Enema
`19.538%m$2859:
`o.—zofiomzzoowMU_”—mop>52Io<t<
`03mm?.
`
`
`33maooG
`o2fO8e9aPla.rOCrebV.CFRv.CLLb9OOG
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`GOOG-1033
`Google LLC v. RFCyber Corp. / Page 8 of 20
`
`PGR2022-00003
`Apple EX1033 Page 8
`
`

`

`US. Patent
`
`Dec. 3, 2013
`
`Sheet 8 0f 9
`
`US 8,601,266 B2
`
`
`
`Oz_._.w_xmZOmo<wmm=2>>m_z
`
`zOfiomzzOo10F
`
`Nomm
`
`comm
`
`o_>_mmod
`
`zwamm
`
`
`
`mw<wwm=2Q_._<>
`
`m_n_o._m_>2m_
`
`o_>_mmod
`
`zwamm
`
`mo._.<o_n_z_
`
`szmmm02m_
`
`m.._m_<s_:mm_m_
`
`
`
`._.m<._.mxomEo
`
`moh<o_n_z_
`
`
`
`o_>_mmo._o
`
`zo_wmm_w
`
`5mm
`
`
`
`zo_mmm_mXQMIQ
`
`9mm
`
`
`
`
`
`I._._>>mm__._o._.<_>_mm__n__._.Zm_n__
`
`
`
`
`
` mo<mmm=2a.w—H—O._.Qm._.<._m_mmmjam
`
`Oz_mmm_oomn_
`
`
`
`I._._>>ammoomn—
`
`38298%
`
`o:mwod
`
`o018mm
`
`
`
`m_._<._.mszmmm
`
`
`
`z_mm__n=._.2m_n__szwmw
`
`o_>_mmod
`
`szwmm
`
`33maooG
`02fo9e9aPla.roCrebV.CFRv.CLLb9ooG
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`GOOG-1033
`Google LLC v. RFCyber Corp. / Page 9 of 20
`
`PGR2022-00003
`Apple EX1033 Page 9
`
`

`

`US. Patent
`
`31023,
`
`f09
`
`Mmvv
`
`
`KMFZmamommmooma>mozm2mmAJOszoo
`3%a:N3|§
`45:25556o:
`
`
`$2099E8._<_Em><._n_m_oxx‘xx‘xx‘Mamea:w:3%hmo<mmmpz_mmpm<o<S._<zmmEm_v55Bx:
`aFm?
`
`
`
`9G
`
`motzozv
`
`mLmg0O
`
`
`
`
`
`03R.
`
`6ur8,o_‘0.”.mm|my
`
`2eBmw6P6l29D..Mm.
`
`C
`
`30320cl4owm
`
`GOOG-1033
`Google LLC v. RFCyber Corp. / Page 10 of 20
`
`PGR2022-00003
`Apple EX1033 Page 10
`
`

`

`US 8,601,266 B2
`
`1
`MUTUAL MOBILE AUTHENTICATION
`USING A KEY lVIANAGEMENT CENTER
`
`CROSS-RFFFRFNCFS TO RFIATFD
`API’I ,ICATIONS
`
`The present application is a non-provisional application of
`and claims priority to US. Provisional Application No.
`61/319,698, filed on Mar. 31, 2010, the entire contents of
`which are herein incorporated by reference for all purposes.
`
`10
`
`BACKGRO UN D
`
`15
`
`The use of mobile devices has rapidly increased in recent
`years. For example, mobile device users now have the capa—
`bility to make payments using their mobile phone. While
`mobile payments provide a convenient tool for a consumer,
`mobile payments may also present security concerns. Sensi-
`tive information, such as a consumer’s personal information,
`account information, etc. can be prone to interception, Addi-
`tionally, if the mobile device is lost or stolen, such infonna-
`tion can be used by an unauthorized user. Furthermore, as
`mobile payment applications evolve. there is a need not only
`to protect information sent from the mobile device, but also to '
`protect information sent to the mobile device during trans—
`mission.
`For example, when payments are made using a physical
`card with an embedded chip, the issuer associated with the
`payment card can update data in the chip during the course of
`a payment transaction. Chip data may be returned in the
`payment transaction response that contains authentication
`data or scripts for updating risk parameters and payment
`counters in the chip payment application. These issuer
`updates require the card to be inserted into a contact point-
`of—sale terminal. If a mobile device is used as a payment
`device, the mobile device cannot be inserted into a point-of-
`sale terminal to conduct a contact point—of—sale transaction
`and to receive issuer updates. Thus, there is an additional need
`for an issuer update solution for mobile devices that are used
`as oayment devices.
`
`Embodiments of the present technology address these and
`other problems.
`
`30
`
`35
`
`40
`
`2
`the challenge response message is valid. The first entity can
`be, for example, an issuer associated with the consumer
`device.
`Another embodiment of the technology is directed at a
`method of authentication. The method includes receiving a
`challenge response message at a key management center from
`a consumer device via a mobile gateway,
`the challenge
`response message being received in response to a challenge
`message sent by the mobile gateway to the consumer device,
`wherein the consumer device is configured for use as a pay—
`ment device. The method also includes determining whether
`the challenge response message is valid and sending a secure
`channel response message from the key management center
`to the consumer device ifthe challenge response message is
`valid. The secure channel response message allows commu-
`nication between the consumer device and a first entity.
`Another embodiment of the technology is directed at a
`system. The system includes a mobile gateway and a key
`management center. The mobile gateway is configured to
`send a challenge message to a consumer device and receive a
`challenge response message from the consumer device in
`response to the challenge message, wherein the consumer
`device is configured for use as a payment device. The key
`management center is in communication with the mobile
`gateway and is configured to receive the challenge response
`message from the mobile gateway, determine whether the
`challenge response message is valid, and send a secure chan—
`nel response message to the consumer device if the challenge
`response message is valid. The secure chalmel response mes—
`sage allows communication between the consumer device
`and a first entity.
`Another embodiment of the technology is directed at a
`server computer. The server computer comprises a processor
`and a computer-readable storage medium having code
`embodied thereon, wherein the code is configured to cause
`the processor to perform a method. The method includes
`receiving a challenge response message from a consumer
`device Via a mobile gateway, the challenge response message
`being received in response to a challenge message sent by the
`mobile gateway to the consumer device, wherein the con—
`sumer device is configured for use as a payment device. The
`method further includes determining whether the challenge
`response message is valid and sending a secure channel
`response message to the consumer device if the challenge
`response message is valid. The secure channel response ines-
`sage allows communication between the consumer device
`and a first entity.
`These and other embodiments of the technology are
`described in further detail below.
`
`
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`FIG. 1 illustrates a transaction flow diagram within a
`mobile gateway context.
`FIG. 2 illustrates a detailed flow diagram of the fimction-
`ality of the mobile gateway and the key management center.
`FIG. 3 illustrates an example of protocols used for com-
`munication.
`FIG. 4 depicts a block diagram of an exemplary consumer
`device.
`FIG. 5 illustrates an exemplary [low diagram for provision-
`ing a consumer device.
`FIG. 6 depicts an exemplary flow diagram for authentica-
`tion in a distributed system.
`FIG. 7 depicts an exemplary flow diagram for authentica-
`tion in an integrated system.
`
`
`
`BRIEF SUMMARY
`
`Aspects of the embodiments of the present technology
`relate in general to improved systems and method for authen—
`tication. Such systems and methods improve the security of
`information transferred to and from a mobile device by
`authenticating the mobile device via a third party mobile
`gateway before infonnation is transmitted.
`One embodiment ofthe technology is directed at a method
`of authentication. The method includes sending a challenge
`message from a mobile gateway to a consumer device, the
`challenge message being sent in response to a communication
`request message, wherein the consumer device is configured
`for use as a payment device. The method further includes
`receiving a challenge response message from the consumer
`device at the mobile gateway in response to the challenge
`message. The method further includes sending the challenge
`response message from the mobile gateway to a key manage-
`ment center, wherein the key management center is config-
`ured to manage session keys for communication with the
`consumer device. The key management center verifies the
`challenge response message and allows a communication
`transaction between a first entity and the consumer device if
`
`45
`
`50
`
`55
`
`60
`
`65
`
`GOOG-1033
`Google LLC v. RFCyber Corp. / Page 11 of 20
`
`GOOG-1033
`Google LLC v. RFCyber Corp. / Page 11 of 20
`
`PGR2022-00003
`Apple EX1033 Page 11
`
`

`

`US 8,601,266 B2
`
`3
`FIG. 8 illustrates an exemplary flow diagram for establish—
`ing a secure session using a new TCP connection.
`FIG. 9 illustrates an exemplary flow diagram for establish—
`ing a secure session using an existing TCP connection.
`FIG. 10 depicts an exemplary block diagram of a computer
`apparatus.
`
`DETAILED DESCRIPTION
`
` Embodiments disclosed herein are directed to techniques
`for authenticating a consumer device to create a secure chan—
`nel for communication between the consumer device and a
`first entity. The consumer device can be, for example, a
`mobile phone, which can be configured for use as a payment
`device that is associated with a payment processing network.
`The consumer device can be provisioned with payment-re-
`lated applications and can be authenticated via a third-party
`mobile gateway using challenge-response authentication. As
`a specific example, when the consumer device requests com-
`munication with a particular entity (e.g. an issuer bank) via
`the application on the consumer device, the communication
`request is sent to the mobile gateway. In response, the mobile
`gateway sends a challenge message to the consumer device.
`The consumer returns a challenge response message to the
`mobile gateway via the application on the consumer device.
`
` The mobile gateway sends the challenge response to a key
`
`management center for validation. The key management cen-
`ter manages session keys for consumer device communica-
`tions with different entities and may be associated with the
`payment processing network. The key management center
`determines whether the received challenge response message
`is valid. If the challenge response message is valid, a secure
`channel response message is returned to the mobile gateway
`and to the consumer device via the mobile gateway. The
`secure channel response message includes a session key
`which allows the consumer device to communicate with the
`first entity via a secure channel for any of a number of types
`of communications. For example, if the first entity is the
`issuer bank associated with the consumer device, the secure
`channel could be used to send issuer updates to the consumer
`device.
`
`Embodiments of the present technology provide a number
`of advantages. The mobile gateway architecture provides
`increased security by authenticating the consumer device
`before allowing communication. Furthemiore, establishing a
`secure channel with session keys provides increased protec—
`tion for the information being transmitted via the channel.
`Additionally, because the mobile gateway architecture for
`creating the secure chaimel is centralized the architecture
`provides flexibility for several entities that may wish to trans-
`mit information to and from the consumer device.
`Prior to discussing the specific embodiments of the tech-
`nology, a further description of some tenns can be provided
`for a better understanding of embodiments ofthe technology.
`An "issuer” can be any bank that issues and maintains a
`financial account for a consumer.
`An “acquirer” can be any bank that provides and maintains
`a financial account for the merchant.
`A “payment processing network” may include data pro—
`cessing subsystems, networks, and operations used to support
`and deliver authorization services, exception file services,
`and clearing and settlement services.
`An “authorization request message” may be a message that
`includes information such as, e.g., a fonn factor of the con-
`smner device or an issuer account
`identifier. The issuer
`accotmt identifier may be a payment account identifier asso-
`ciated with a payment device (e.g. a consumer device). The
`
`q
`
`10
`
`15
`
`'
`
`30
`
`35
`
`40
`
`45
`
`50
`
`55
`
`60
`
`65
`
`4
`authorization request message may request that an issuer of
`the payment device authorize a transaction. An authorization
`request message according to an embodiment of the technol—
`ogy may comply with ISO 8583, which is a standard for
`systems that exchange electronic transactions made by
`account holders using payment devices.
`A “server computer” can be a powerful computer or a
`cluster of computers. For example, the server computer can
`be a large mainframe, a minicomputer cluster, or a group of
`servers functioning as a unit. In one example, the server
`computer may be a database server coupled to a Web server.
`FIG. 1 depicts a transaction flow diagram within a mobile
`gateway context. For simplicity of discussion, only one of
`each component is shown. It is understood, however, that
`embodiments ofthe technology may include more than one of
`each component. Additionally, some embodiments of the
`teclmology may include fewer than all of the components
`shown in FIG. 1. Furthermore, the components in FIG. 1 may
`communicate via any suitable communication medium (in—
`cluding the Internet), using any suitable communication pro—
`tocol. FIG. 1 depicts an example of the system in which a
`mobile gateway and a key management center may be imple—
`mented
`FIG. 1 shows a system that can be used in an embodiment
`of the technology. The system includes an access device 106,
`such as a contactless payment point-of-sale (POS) payment
`tenninal, at a merchant and an acquirer 110 associated with
`the merchant. In a typical payment transaction, a consumer
`may purchase goods or services at the merchant via the access
`device 106 using a mobile consumerdevice 104. The acquirer
`110 can communicate with an issuer 114 via a payment pro-
`cessing network 112.
`The consumer may be an individual or an organization,
`such as a business that is capable of purchasing goods or
`services.
`The consumer device 104 may be in any suitable form for
`contactless payment. For example, suitable consumer devices
`can be hand-held and compact so that they can fit into a
`consmner’s wallet and/or pocket (e.g., pocket-sized). The
`consumer device 104 typically comprises a processor, a
`memory, input device, output devices, and near-field commu-
`nication (NFC) devices, all of which are operatively coupled
`to the processor. Specific examples of consumer devices can
`include fomis of portable communication devices, such as
`cellular or wireless phones, tablets, smartphones, personal
`digital assistances (PDAs), pagers, portable computers, and
`the like. In some embodiments, the consumer device 1 04 may
`be associated with multiple financial accounts. such as being
`associated with different payment accounts (e.g., credit,
`debit. or prepaid). Likewise, it is possible for the consumer to
`have multiple consumer devices 104 that are associated with
`the same underlying financial accotmt.
`The payment processing network 112 may include data
`processing subsystems, networks, and operations used to sup-
`port and deliver authorization services, exception file ser-
`vices, and clearing and settlement services. An exemplary
`payment processing network may include VisaNetTM. Pay-
`ment processing networks such as VlsaNetTM are able to
`process credit card transactions, debit card transactions, and
`other types of commercial transactions. VisaNetTM, in par-
`ticular includes a Visa Integrated Payments (VIP) system
`which processes authorization requests and a Base II system
`which perfonns clearing and settlement services. Further-
`more, the payment processing network 112 may include a
`server computer and may use any suitable wired or wireless
`network, including the Internet.
`
`
`
`GOOG-1033
`Google LLC v. RFCyber Corp. / Page 12 of 20
`
`GOOG-1033
`Google LLC v. RFCyber Corp. / Page 12 of 20
`
`PGR2022-00003
`Apple EX1033 Page 12
`
`

`

`US 8,601,266 B2
`
`10
`
`15
`
`30
`
`35
`
`40
`
`5
`The merchant can have, or may receive communications
`from, an access device 106 that can interact with the con-
`sumer device 104, such as a contactless FOS device. The
`access device 106 according to embodiments of the technol-
`ogy can be in any suitable form for accessing data on a
`contactless consumer device. Examples ofaccess devices can
`include FOS devices, cellular phones, FDAs, personal com-
`puters (PCs), tablet FCs, handheld specialized readers, set-
`top boxes, electronic cash registers, automated teller
`machines (ATMs), virtual cash registers, kiosks, security sys—
`tems, access systems, and the like. The access device 106 may
`include any suitable contact or contactless mode of operation
`(e.g., radio frequency (RF) antennas, NFC devices, etc).
`In a typical purchase transaction, the consumerpurchases a
`good or service via the merchant’s access device 106 using
`the consumer device 1 04. The consumer device 104 can inter-
`act with an access device 106 such as a contactless FUS
`terminal at the merchant For example, the consumer may
`take a wireless phone and may pass it near a contactless reader
`in a PCS terminal.
`An authorization request mes sage is then forwarded from
`the access device 106 to the acquirer 110. After receiving the
`authorization request mes sage at the acquirer 110, the autho—
`rization request message is then sent to the payment process—
`ing network 112. The payment processing network 112 then '
`forwards the authorization request message to the issuer 114
`of the consumer device 104.
`After the issuer 1 14 receives the authorization request ines-
`sage, the issuer 114 sends an authorization response message
`back to the payment processing network 112 to indicate
`whether or not the current transaction is authorized (or not
`authorized). The payment processing network 112 then for-
`wards the authorization rcsponsc message back to the
`acquirer 110. The acquirer 110 then sends the response mes—
`sage back to the merchant.
`After the merchant receives the authorization response
`message, the access device 106 at the merchant may then
`provide the authorization response mes sage for the consumer.
`The response message may be displayed by the access device
`106 or may be printed out on a receipt.
`At the end of the day, a normal clearing and settlement
`process can be conducted by the payment processing network
`112. A clearing process is a process of exchanging financial
`details between an acquirer and an issuer to facilitate posting
`to a consumer’s account and reconciliation ofthe consumer’s
`settlement position. Clearing and settlement can occur simul—
`taneously. Typically, the merchant sends the clearance infor—
`mation to the acquirer at the end of the day, and the acquirer
`and issuer can subsequently facilitate the clearing and settle-
`ment process.
`The mobile gateway 152 and the mobile key management
`center 150 can be used when over-the-air (OTA) messages
`need to be sent between the consumer device 104 and a first
`entity, The mobile gateway 152 provides the link to consumer
`devices over which services can be offered by entities such as
`issuers, payment processing networks, and other processors.
`The mobile gateway 152 can facilitate a challenge-response
`authentication of the consumer device 104. If the consumer
`device 152 is authenticated, the key management center 150
`can provide session keys for a secure communication chan—
`nel. The secure communication channel allows the consumer
`device 104 to securely access services provided by the pay-
`ment processing network 112. More details about the func-
`tionality of the mobile gateway 152 and the key management
`center 150 are provided below.
`FIG. 2 illustrates a detailed flow diagram of the function-
`ality of the mobile gateway 152 and the key management
`
`45
`
`50
`
`55
`
`60
`
`65
`
`6
`center 150. As discussed above, the mobile gateway 152 and
`the key management center 150 provide security for the ser-
`vices offered to the consumer on the consumer device 104. It
`should be noted that there may be differences in the architec-
`ture of FIG. 2 depending on a variety of factors. For example,
`there may be differences depending on whether the F08
`infra structure is one which goes online to the issuer for trans-
`action authorization or one which supports offline authorized
`transactions. Furthermore, it should be noted that while FIG.
`2 shows OTA provisioning, other embodiments may utilize
`pre—provisioned consumer devices.
`A mobile gateway 152 is a platform capable of providing
`secure services to a consumer device 106 via OTA messages
`over a secure channel. The mobile gateway 152 supports
`mobile contactless payments, such as those depicted in FIG.
`1, and is utilized in a maimer which enables the addition of
`future supporting services as the need arises.
`In order to provide services to a consumer device 104 that
`supports contactless payments securely, the mobile gateway
`152 supports two request-response message pairs. One
`request-response message pair is used to prepare the secure
`chalmel. This message pair allows the consumer device 104
`and the mobile gateway 152 to exchange initial information.
`The second request—response mes sage pair is used to establish
`the secure channel. This message pair allows the consumer
`device 104 and the mobile gateway 152 to mutually authen-
`ticate and allows the consumer device to receive session keys
`from the mobile gateway 152. Once the secure channel is
`established, the session keys are used to protect the confiden-
`tiality and integrity of the messages used by the supported
`services as appropriate to the needs of that service.
`The transaction flow can be initiated Via either a “pull” or
`a “push” situation. In a “pull” situation, the transaction is
`initiated by the consumer via interaction with the consumer
`device application or by the consumer device application
`itself due to a specific payment application status (e.g., when
`offline risk management parameters are low). In a “push”
`situation, the issuer initiates the transaction [low by sending a
`push mes sage to the consumer device 106. However, the basic
`transaction flow is similar irrespective of how it is initiated.
`That is, a secure chamiel is first prepared and established, and
`then a specific service is requested utilizing the established
`secure channel.
`The mobile payment application (MFA) 154 is a payment
`application that is installed in a secure clement (SE) chip
`within a NFC—enabled consumer device 104. The MFA 154
`provides the functionality to manage and maintain the con—
`sumer’ s payment information and support mobile contactless
`payments. During a payment transaction, the MFA 154 inter-
`acts with the access device 106 over the contactless interface
`to enable the mobile payment transaction. The entity issuing
`the MFA 154 to the consumer device 104 is typically a mem-
`ber of the payment processing network 112. In one embodi-
`ment, the entity issuing the MFA 154 is the issuer 114.
`The MFA 154 also interfaces with the mobile application
`(MA) 156 on consumer device l04. The MA l56 is the
`consumer device application that provides a user interface for
`consumer interaction (e.g., to enter and View information).
`The MA 156 also communicates with the MFA 154 to retrieve
`and return information during the processing of any of a
`number of services offered to the consumer via the consumer
`device 104 (e.g., issuer update processing). Additionally, the
`MA 156 can communicate with the mobile gateway 152 to
`send and receive OTA messages.
`The MFA 154 and the MA 156 may use data encryption
`standards such as, e.g., RSA with a key of at least 1024 hits,
`triple data encryption standard (DES), 128-bit advanced
`
`GOOG-1033
`Google LLC v. RFCyber Corp. / Page 13 of 20
`
`GOOG-1033
`Google LLC v. RFCyber Corp. / Page 13 of 20
`
`PGR2022-00003
`Apple EX1033 Page 13
`
`

`

`US 8,601,266 B2
`
`
`
`
`
`7
`encryption standard (AES). an RC4 stream encryption algo—
`rithm using minimum 128—bit key length, etc. These encryp—
`tion standards may be used to create the secure session.
`The SE is used by the consumer device l04 to host and
`store data and applications that require a high degree of secu-
`rity. The SE is provided to the consumer device 104 by the SE
`issuer 125. The SE issuer 125 may not necessari y be a mem-
`ber ofthe payment processing network 112 or the same entity
`as the issuer 114 ofthe payment instrument (e.g. MPA 154 on
`the consumer device 106). For example, the SE issuer 125
`may be a mobile network operator (MNO).
`The MPA 154 can be installed within the SE to manage and
`maintain the security of payments. The entity issuing the
`MFA 154 may need a key and/or a token to install and per-
`sonalize the MPA 154 on the SE. These keys may generally be
`managed on the issuer’ s behalfby a personalization bureau or
`Trusted Service Manager (TSM) 120. That is, these keys may
`be provided by the SE issuer 125 to the TSM 120 (S404).
`The TSM 120 offers services to support mobi e financial
`services. The basic functionalities that may be provided by
`the TSM 120 include the ability to manage SE keys for
`installing and configuring MPA 154 over the air. The TSM
`120 may also be integrated with issuer systems for activating
`and personalizing the MPA 154 with consumers’ payment
`information (S402). Upon receiving the activation request.
`the TSM 120 may provision the MA 156 and the MPA 154
`over the air (S406 and S408). The TSM 120 may also lock or
`unlock the SE on the consumer device 104 (S410). Once
`activated, the TSM 120 may send an activation confirmation
`to the mobile gateway 152 (S412).Additionally, the TSM 120
`
`may provide ongoing SE platform management and support.
`Consumer devices 104 that support mobile contactlcss
`payments typically support contactless transactions using the
`EMV contactless communication protocol
`(EMV—CCP),
`which is based on ISO 14443, in order to interact with mer—
`chant access devices 106. This capability is typically met by
`implementing NFC. The NFC capability on the consumer
`device 104 might be enabled by an embedded NFC chip or by
`the addition of an external memory card or accessory that
`contains the NFC chip. Additionally, the consumer device
`104 typically includes the SE either embedded in the handset
`or in the subscriber identity module (SIM). The SE can also be
`included in an add-on device such as a micro-Secure Digital
`(microSD) card.
`As discussed above, the mobile gateway 152 allows con—
`sumer devices 104 to access services from the issuer 114 via
`the payment processing network 112. such as. e.g., issuer
`updates. The mobile gateway 152 provides a secure charmel
`over which information can be transmitted securely through
`the consumer device 106 and over the mobile network and
`Internet. Mobile gateways 152 may be implemented by issu-
`ers, acquirers, third-party services providers, or TSMs 120.
`The mobile gateway 152 uses the key management center
`150 to set up a secure mutually authenticated channel with a
`MPA l54 instance in the consumer device [04. As part ofthis
`process, cryptographic keys may be used to enable the
`authentication ofthe MPA 154 to the key management center
`
`150. Each MPA 154 instance is personalized with unique keys
`derived from an issuer—specific set of master keys. T