US0093.1785OB2
`
`(12) United States Patent
`Keresman, III et al.
`
`(10) Patent No.:
`(45) Date of Patent:
`
`US 9,317,850 B2
`Apr. 19, 2016
`
`(54)
`
`(75)
`
`(73)
`
`(*)
`
`(21)
`(22)
`(65)
`
`(60)
`
`(51)
`
`(52)
`
`METHOD AND SYSTEM FOR PROCESSING
`PIN DEBIT TRANSACTIONS
`
`Inventors: Michael A. Keresman, III, Kirtland
`Hills, OH (US); Paul Turgeon, Chicago,
`IL (US)
`Assignee: CardinalCommerce Corporation,
`Mentor, OH (US)
`Subject to any disclaimer, the term of this
`patent is extended or adjusted under 35
`U.S.C. 154(b) by 186 days.
`Appl. No.: 13/080,119
`Filed:
`Apr. 5, 2011
`
`Notice:
`
`Prior Publication Data
`US 2011/0246324 A1
`Oct. 6, 2011
`
`Related U.S. Application Data
`Provisional application No. 61/320,868, filed on Apr.
`5, 2010.
`
`(2012.01)
`(2012.01)
`(2012.01)
`(2012.01)
`(2012.01)
`(2012.01)
`(2012.01)
`(2012.01)
`
`Int. C.
`G06O20/00
`G06O20/38
`G06O20/08
`G06O20/12
`G06O 30/06
`G06O20/02
`G06O20/24
`G06O20/26
`U.S. C.
`CPC .............. G06O20/385 (2013.01); G06O20/02
`(2013.01); G06O20/0855 (2013.01); G06Q
`20/12 (2013.01); G06O20/24 (2013.01); G06Q
`20/26 (2013.01); G06O20/383 (2013.01);
`G06O 30/0613 (2013.01)
`
`(58) Field of Classification Search
`CPC ........................... G06Q 20/385; G06Q 30/383
`USPC .......................................... 705/39, 44, 64, 67
`See application file for complete search history.
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`6.254,000 B1* 7/2001 Degen et al. .................. 235,380
`6,327,578 B1* 12/2001 Linehan .......................... 705/65
`6,901,387 B2
`5, 2005 Wells et al.
`6,908,030 B2
`6/2005 Rajasekaran et al.
`(Continued)
`
`FOREIGN PATENT DOCUMENTS
`
`JP
`JP
`
`9, 2001
`2001-2564O7
`2, 2004
`2004-054897
`(Continued)
`OTHER PUBLICATIONS
`
`Ron White, “How Computers Work”, Oct. 15, 2003, Que.*
`PCT International Search Report dated May 27, 2011.
`Primary Examiner — Steven Kim
`(74) Attorney, Agent, or Firm — Fay Sharpe LLP
`(57)
`ABSTRACT
`A system for processing a debit transaction between a mer
`chant and a consumer. The system includes one or more
`processors programmed to receive payment information for
`the consumer, collect authentication data for the debit card
`from the consumer, transmit an alias account number unique
`to the debit transaction to the merchant, receive a credit autho
`rization message including the alias account number from the
`merchant, translate the credit authorization message to a debit
`authorization message using the authentication data, and
`transmit the debit authorization message to a payment pro
`CSSO.
`
`18 Claims, 3 Drawing Sheets
`
`
`
`103
`
`182
`
`176
`
`178
`
`COWAC)
`ERX
`
`HRE PARY
`
`PROCESSOR
`
`MEWRY
`
`COA.NE
`
`AABASE
`
`Ex.1007
`APPLE INC. / Page 1 of 13
`
`

`

`US 9,317,850 B2
`Page 2
`
`(56)
`
`References Cited
`
`U.S. PATENT DOCUMENTS
`
`6,980,970 B2 * 12/2005 Krueger ................. G06Q 20/02
`705/38
`7,039,603 B2 * 5/2006 Walker ................... G06Q 20/00
`TO5/1413
`7,051,002 B2
`5/2006 Keresman, III et al.
`7,069,249 B2 * 6/2006 Stolfo et al. .................... 705/74
`7,225,156 B2 * 5/2007 Fisher .................... G06Q 20/02
`235,379
`
`4/2008 Bezos et al.
`7,356,507 B2
`5, 2008 Mizrah
`7,379,916 B1
`7, 2008 Pinnell
`7,398,253 B1
`8, 2008 Nelson
`7,413, 112 B2
`10/2008 White et al.
`7,434,723 B1
`1/2009 Brown
`7,472,829 B2
`2, 2009 Zhu
`7,494,067 B1
`5/2009 Leblang et al.
`7,536,351 B2
`6/2009 Caplanet al.
`7,542,943 B2
`6, 2009 Brown et al.
`7,543,739 B2
`7/2009 Flitcroft et al.
`7,567,934 B2
`8, 2009 Horrocks et al.
`7,577.585 B2
`8, 2009 Brown et al.
`7580898 B2
`9/2009 Wells et al.
`7.584,151 B2
`7,606,766 B2 10/2009 Anderson et al.
`7,606,770 B2 10/2009 Pinnell
`7,693,783 B2
`4/2010 Balasubramanian et al.
`7,770,789 B2* 8/2010 Oder, II .................. G06Q 20/20
`235,380
`7.841,523 B2 * 1 1/2010 Oder, II .................. G06Q 20/20
`235,380
`7,891,563 B2 * 2/2011 Oder, II .................. G06Q 20/20
`235,380
`2002/011 1907 A1* 8/2002 Ling ............................... TOS/41
`
`7, 2003 Fisher et al.
`2003/O126094 A1
`2003/0182558 A1* 9, 2003 Lazzaro ............. G06Q 30/0641
`T13, 183
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`2003/0226042 A1 12/2003 Fukushima
`2004/0044739 A1* 3/2004 Ziegler ................... G06Q 20/02
`TO9,213
`. 29:
`3.92. A. : 2. M. t
`OWS a.
`705/67
`2005.0246290 A1* 11/2005 Kausik.
`... 726/2
`2006/0123465 A1* 6/2006 Ziegler ...
`705/64
`2006/0242085 A1 * 10, 2006 Jones et al. ..
`705/39
`2007,01922.45 A1* 8, 2007 Fisher et al. .
`2007/0271179 A1* 11/2007 Kubota ........................... 705/39
`2008/0040274 A1
`2/2008 UZO ................................ TO5/44
`2008/0097925 A1 * 4/2008 King ............................... 705/67
`2008/0275748 A1 11/2008 John
`2009/0037982 A1
`2/2009 Wentker et al.
`2009/0083159 A1
`3/2009 Maw ............................... 705/17
`2009. O157518 A1
`6/2009 Bishop et al.
`2009/0271262 A1* 10, 2009 Hammad ............... G06Q 20/04
`TO5/1433
`2009/0313147 A1 12/2009 Balasubramanian et al.
`2010.0057554 A1
`3/2010 Lanford ..................... TO5, 14.38
`2010.008820.6 A1* 4/2010 Lister .............................. TOS/34
`2010.0153272 A1* 6, 2010 Wentker .................. G06F 21.33
`ck
`TO5/44
`2011 0180598 A1
`7/2011 Morgan et al. ................ 235,380
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`.
`
`
`
`FOREIGN PATENT DOCUMENTS
`
`2007-286697
`JP
`2008-158638
`JP
`2008-305392
`JP
`WO WO 2008, 131021
`* cited by examiner
`
`11, 2007
`T 2008
`12/2008
`10, 2008
`
`Ex.1007
`APPLE INC. / Page 2 of 13
`
`

`

`U.S. Patent
`
`Apr. 19, 2016
`
`Sheet 1 of 3
`
`US 9,317,850 B2
`
`901
`
`DO 8 d.
`
`OOT
`
`ZIT
`
`ZZI
`
`
`
`
`
`
`
`
`
`
`
`8/I
`
`Ex.1007
`APPLE INC. / Page 3 of 13
`
`

`

`U.S. Patent
`
`Apr. 19, 2016
`
`Sheet 2 of 3
`
`US 9,317,850 B2
`
`
`
`t
`
`
`
`Sae BABES
`
`89 I
`
`
`
`} |N în SNO]] VO?NOHAWNOD09Tl
`
`37 I
`
`Ex.1007
`APPLE INC. / Page 4 of 13
`
`

`

`U.S. Patent
`
`Apr. 19, 2016
`
`Sheet 3 of 3
`
`US 9,317,850 B2
`
`AOO Z
`
`AO2
`
`404
`
`4O6
`
`AO8
`
`RECEIVE PAYMENT INFORMATION
`
`COLLECT AUTHENTICATION DATA
`
`RANSMITAN ALAS ACCOUNT NUMBER
`
`RECEIVE ACREDTAUTHORIZATION MESSAGE
`
`41 O
`
`TRANSLATE THE CREDIT AUTHORIZATION MESSAGE
`
`412
`
`TRANSMIT A DEBT AUTHORIZATION MESSAGE
`
`414
`
`RECEIVE A DEBT AUTHORIZATION RESPONSE MESSAGE
`
`416
`
`TRANSLATE THE DEBT AUTHORIZATION RESPONSE MESSAGE
`
`418
`
`TRANSMTA CREDTAUTHORIZATION RESPONSE MESSAGE
`
`FG. 4
`
`Ex.1007
`APPLE INC. / Page 5 of 13
`
`

`

`US 9,317,850 B2
`
`1.
`METHOD AND SYSTEM FOR PROCESSING
`PIN DEBIT TRANSACTIONS
`
`This application claims the benefit of U.S. Provisional
`Application No. 61/320,868, filed Apr. 5, 2010, incorporated
`herein by reference in its entirety.
`
`BACKGROUND
`
`The present exemplary embodiment relates to electronic
`commerce (or e-commerce). It finds particular application in
`conjunction with personal identification number (PIN) debit
`cards, and will be described with particular reference thereto.
`However, it is to be appreciated that the present exemplary
`embodiment is also amenable to other like applications.
`By way of background, Internet commerce, or e-commerce
`as it is otherwise known, relates to the buying and selling of
`products and/or services between consumers and merchants
`over the Internet or other like transactional exchanges of
`information. The convenience of shopping over the Internet
`has sparked considerable interest in e-commerce on behalf of
`both consumers and merchants. In the United States, the
`fastest growing card type is the PIN debit card. However,
`today there is no ubiquitous way to use a PIN debit card on the
`Internet.
`The present invention contemplates new and improved
`systems and/or methods which overcome the above-refer
`enced problems and others.
`
`10
`
`15
`
`25
`
`INCORPORATION BY REFERENCE
`
`30
`
`The following commonly assigned applications, the dis
`closures of each being completely incorporated herein by
`reference, are mentioned:
`U.S. Pat. No. 7,051,002 entitled “Universal Merchant Plat
`form for Payment Authentication.” by Keresman, III et al.:
`and,
`U.S. Pat. No. 7,693,783 entitled “Universal Merchant Plat
`form for Payment Authentication.” by Balasubramanian et
`al.
`
`35
`
`40
`
`BRIEF DESCRIPTION
`
`2
`The payment information identifying a debit card. Authenti
`cation data for the debit card is collected from the consumer.
`An alias account number unique to the debit transaction is
`transmitted to the merchant and a credit authorization mes
`sage including the alias account number is received from the
`merchant. The credit authorization message is translated to a
`debit authorization message using the authentication data and
`the debit authorization is transmitted to a payment processor.
`One advantage resides in the ability to use a PIN debit card
`to complete an Internet purchase.
`Another advantage resides the ability to reduce risk of
`identity theft or fraud.
`Another advantage resides in the ability to minimize
`changes required of organizations that process merchant pay
`ment transactions.
`Still further advantages of the present invention will be
`appreciated to those of ordinary skill in the art upon reading
`and understanding the following detailed description.
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`The presently disclosed subject matter may take form in
`various components and arrangements of components, and in
`various steps and arrangements of steps. The drawings are
`only for purposes of illustrating preferred embodiments and
`are not to be construed as limiting. Further, it is to be appre
`ciated that the drawings are not to Scale.
`FIG. 1 is a block diagram of a system for processing debit
`transactions according to aspects of the present disclosure;
`FIG. 2 is a block diagram of a payment processing Supply
`chain;
`FIG.3 is a block diagram of the functional components of
`a converter according to aspects of the present disclosure;
`and,
`FIG. 4 is a method for processing debit transactions
`according to aspects of the present disclosure.
`
`DETAILED DESCRIPTION
`
`With reference to FIG. 1, a block diagram of a system 100
`for processing debit transactions, such as PIN debit transac
`tions, is shown. The system 100 suitably includes one or more
`consumers 102, one or more merchants 104, at least one
`payment processing Supply chain 106, a third party 108 pro
`viding a universal merchant platform (UMP) 110, and the
`like, interconnected by a communications network 112. The
`communications network 112 is typically the Internet, but
`other communications networks are contemplated. For
`example, the communications network 112 may include one
`or more of a local area network, a wireless network, and the
`like.
`The consumers 102 may electronically purchase products
`and/or services from the merchants 104 over the communi
`cations network 110 via graphical user interfaces, such as
`e-commerce websites, of the merchants 104. In that case, the
`consumers 102 may employ web browsers to access the
`graphical user interfaces and purchase the products and/or
`services. However, it is to be appreciated that other means of
`electronically purchasing the products and/or services are
`contemplated. For example, stand-alone programs embody
`ing the graphical user interfaces can be distributed, optionally
`via the communications network 110, to the consumers 102.
`To purchase the products and/or services over the communi
`cations network 112, the consumers 102 submit a payment
`type to the merchants 104. A payment type includes, for
`example, PIN debit card, credit card, and so on.
`
`Various details of the present disclosure are hereinafter
`Summarized to provide a basic understanding. This Summary
`is not an extensive overview of the disclosure and is intended
`neither to identify certain elements of the disclosure, nor to
`delineate the scope thereof. Rather, the primary purpose of
`the Summary is to present certain concepts of the disclosure in
`a simplified form prior to the more detailed description that is
`presented hereinafter.
`In accordance with one aspect, a system for processing a
`debit transaction between a merchant and a consumer is pro
`vided. The system includes one or more processors pro
`grammed to receive payment information for the consumer,
`collect authentication data for the debit card from the con
`Sumer, transmit an alias account number unique to the debit
`transaction to the merchant, receive a credit authorization
`message including the alias account number from the mer
`chant, translate the credit authorization message to a debit
`authorization message using the authentication data, and
`transmit the debit authorization message to a payment pro
`cessor. Payment information for the consumer is received
`from the merchant.
`In accordance with another aspect, a method for processing
`a debit transaction between a merchant and a consumer is
`provided. Payment information for the consumer is received.
`
`45
`
`50
`
`55
`
`60
`
`65
`
`Ex.1007
`APPLE INC. / Page 6 of 13
`
`

`

`3
`Each of the consumers 102 is suitably embodied by a
`digital processing device 114. Such as a computer, Smart
`phone, PDA, and the like, connected to the communications
`network 112. Further, each of the digital processing devices
`114 Suitably includes a communications unit 116, at least one
`memory 118, a display 120, a user input device 122, a pro
`cessor 124, and the like. The communications units 116 allow
`the digital processing devices 114 to interact with other com
`ponents connected to the communications network 112. The
`memories 118 include computer executable instructions for
`performing the above-noted functions associated with the
`consumers 102. The displays 120 display the graphical user
`interfaces (e.g., via web browsers) facilitating consumer
`interaction with the digital processing devices 114. The user
`input devices 122 allow the consumers 102 to interact with the
`graphical user interfaces. The processors 124 execute the
`computer executable instructions on the memories 118.
`The merchants 104 provide the consumers 102 the graphi
`cal user interfaces, typically via the communications network
`112. For example, it is contemplated that the graphical user
`interfaces are e-commerce websites. The graphical user inter
`faces suitably allow the consumers 102 to purchase products
`and/or services electronically over the communications net
`work 112 through Submission of payment types. For example,
`the graphical user interfaces allow consumers 102 to select
`and Submit products and/or services to purchase and select
`and Submit a payment type for payment therefor to the mer
`chants 104.
`When a merchant receives the payment type from a con
`Sumer, the merchant submits the payment type to the UMP
`30
`110 and places the consumer in communication with the
`UMP 110 via, for example, an iFrame, a redirect to the UMP
`110, and so on. The UMP 110 collects payment information,
`Such as a card number and expiration date, for the payment
`type from the consumer and partially or wholly completes the
`35
`transaction using the payment type. For example, the UMP
`110 collects payment information for the payment type and
`processes transactions involving PIN debit cards. As another
`example, the UMP 110 for collects payment information for
`the payment type and processes transactions involving
`authenticated payment initiatives. Although the UMP 110 can
`be employed to wholly complete a transaction, it is typically
`employed to partially complete a transaction. In that regard,
`the merchant Suitably performs the authorization and capture
`of funds typical of credit card transactions and offloads, for
`45
`example, authentication or payment selection to the UMP
`110.
`To use the UMP 110, the merchants 104 suitably register
`with the third party 108 providing the UMP 110. This step
`may include the merchants 104 providing merchant informa
`tion (e.g., financial information, physical address, category of
`goods or services sold, Internet address, email address, etc.)
`to the third party 108. Typically, the merchant information is
`provided over the communications network 112 via a graphi
`cal user interface, such as a web interface, offered by the third
`party 108. However, other means of providing the merchant
`information, Such as via a telephone, are contemplated. Addi
`tionally, the merchant information is suitably modifiable,
`optionally via the graphical user interface and/or the commu
`nications network 112. In certain embodiments, registration
`60
`may further include signing and/or executing an agreement of
`the third party 108.
`Further, to use the UMP 110, the merchants 104 suitably
`augment their graphical user interface and/or backend sys
`tems Supporting the graphical user interfaces to employ the
`UMP 110. For example, a merchant may add a hosted iFrame
`linking their graphical user interface to the third party 108.
`
`50
`
`40
`
`55
`
`65
`
`US 9,317,850 B2
`
`10
`
`15
`
`25
`
`4
`Advantageously, this allows easy integration with the UMP
`110, especially during the Submission of payment informa
`tion. As another example, a merchant may modify their back
`end system to forward all debit PIN transactions to the UMP
`110 for processing.
`One or more servers 126 connected to the communications
`network 112 suitably embody each of the merchants 104.
`Each of the servers 126 includes one or more of a communi
`cations unit 128, at least one memory 130, a processor 132,
`and the like. The communications units 128 allow the servers
`126 to interact with other components connected to the com
`munications network 112. The memory 130 generally
`includes computer executable instructions for performing the
`above-noted functions associated with the merchants 104.
`The processors 132 execute the computer executable instruc
`tions on the memory 130.
`The payment processing Supply chain 106 facilitates the
`transfer of funds from the consumers 102 to the merchants
`104. As shown in FIG. 2, the payment processing Supply
`chain 106 suitably includes one or more issuers 134, one or
`more payment processors 136, and one or more payment
`brand networks 138. In certain embodiments, the payment
`processing Supply chain 106 further includes one or more
`payment gateways (not shown) providing the merchants 104
`with an interface to the payment processors 136.
`The issuers 134 issue payment instruments, such as pre
`paid/stored value cards, debit cards and/or credit cards, to the
`consumers 102. In that regard, the issuers 134 have an account
`relationship with the consumers 102, and one of the issuers
`134 Suitably issues each payment instrument processed by the
`system 100. One or more servers 140 suitably embody each of
`the issuers 134. Each of the servers 140 includes one or more
`of a communications unit 142, at least one memory 144, a
`processor 146, and the like. The communications units 142
`allow the servers 140 to interact with the payment brand
`networks 138, optionally via a communications network,
`such as the communications network 112. The memory 144
`generally includes computer executable instructions for per
`forming the above-noted functions associated with the issuers
`134. The processors 146 execute the computer executable
`instructions on the memory 144.
`The payment processors 136 process purchase and pay
`ment transactions. The payment processors 136 include at
`least one payment processor implementing an Internet
`acquiring platform and, optionally, at least one payment pro
`cessor implementing a debit acquiring platform. Insofar as
`the payment processors 136 do not include a payment pro
`cessor implementing a debit acquiring platform, the third
`party 108 carries out this role. Although not necessary, a
`payment processor can implement both an Internet acquiring
`platform and a debit acquiring platform. Each of the mer
`chants 104 typically employs one or more of the payment
`processors 136 (e.g., as their financial institution and/or
`acquiring bank), where the payment processors for each of
`the merchants implement an Internet acquiring platform and,
`optionally, a debit acquiring platform. A debit acquiring plat
`form processes purchase and payment transactions initiated
`at physical world (card present) merchants and an Internet
`acquiring platform processes purchase and payment transac
`tions initiated at e-commerce (card not present) merchants.
`Typically, the messages used by debit acquiring platforms
`are different from the messages used by Internet acquiring
`platforms. Further, debit networks through which the mes
`sages are routed, discussed below, determine the messages
`used by debit acquiring platforms. Debit acquiring platforms
`typically process debit card transactions using a single mes
`sage, hereafter referred to as a debit authorization message.
`
`Ex.1007
`APPLE INC. / Page 7 of 13
`
`

`

`US 9,317,850 B2
`
`10
`
`15
`
`5
`The debit authorization message is for the purpose ofrequest
`ing authorization to make a purchase, and, for pay as you go
`transactions, if the request is approved, the authorization mes
`sage also serves as the posting record. Internet acquiring
`platforms typically process credit card transactions using a
`dual message structure involving a credit authorization mes
`sage and a credit settlement message. The creditauthorization
`message places a hold on funds, and the credit settlement
`message captures funds from the affected account. Typically,
`the credit settlement messages are Submitted in bulk (i.e.,
`batch Submission) after a predetermined time. Such as the end
`of a business day. In certain embodiments, the messages
`employed by the payment processors 136 are in ISO 8583
`format or another format proprietary to the entity processing
`the transaction.
`One or more servers 148 suitably embody each of the
`payment processors 136. Each of the servers 148 includes one
`or more of a communications unit 150, at least one memory
`152, a processor 154, and the like. The communications units
`150 allow the servers 148 to interact with the payment brand
`networks 138, optionally via a communications network,
`such as the communications network 112. The memory 152
`generally includes computer executable instructions for per
`forming the above-noted functions associated with the pay
`ment processors 136. The processors 154 execute the com
`25
`puter executable instructions on the memory 152.
`The payment brand networks 138 govern and process pur
`chase and payment transactions. In this regard, the payment
`brand networks 138 generally employ network switches to
`process transactions and route them to the issuers 134. Suit
`ably, the payment brand networks 138 include at least one
`debit network. Debit networks include debit network
`Switches to process transactions and route them to the issuers
`134 for approval and posting. An example of a debit network
`is a PIN debit network. A PIN debit network is a payment
`network that governs and processes purchase and payment
`transactions where the consumer is validated through the
`combination of presentment of a plastic card and entry of a
`PIN. Typical debit payment brand networks include STAR,
`NICE, and INTERLINK.
`One or more servers 156 suitably embody each of the
`payment brand networks 138. Each of the servers 156
`includes one or more of a communications unit 158, at least
`one memory 160, a processor 162, and the like. The commu
`nications units 158 allow the servers 156 to interact with
`45
`payment processors 136 and the issuers 134, optionally via a
`communications network, Such as the communications net
`work 112. The memory 160 generally includes computer
`executable instructions for performing the above-noted func
`tions associated with the payment brand networks 138. The
`processors 162 execute the computer executable instructions
`on the memory 160.
`Referring back to FIG. 1, the third party 108 facilitates the
`completion of transactions between the consumers 102 and
`the merchants 104 by way of the UMP 110. The UMP 110
`serves as a centralized merchant processing system to process
`electronic transactions through any payment brand network
`using a single platform. In this regard, it enables merchants to
`process payments, regardless of which payment brand net
`work they are to be routed through, with a single implemen
`tation. For more information pertaining to the basic function
`ality of the UMP 110, attention is directed to, for example,
`U.S. Pat. No. 7,051,002 entitled “Universal Merchant Plat
`form for Payment Authentication.” by Keresman, III et al.,
`and U.S. Pat. No. 7,693,783 entitled “Universal Merchant
`Platform for Payment Authentication.” by Balasubramanian
`et al., both incorporated herein by reference in their entireties.
`
`55
`
`6
`The UMP 110 can also be employed to process e-commerce
`transactions involving debit cards, such as PIN debit cards,
`with minimal modification to existing infrastructure.
`To process transactions involving debit cards, the UMP
`110 receives payment types from the merchants 104. For
`example, a consumer browses a merchant’s e-commerce
`website and selects a product to purchase. Thereafter, the
`consumer chooses to pay for the product and is prompted to
`enter a payment type, such as a PIN debit card. This payment
`type is then submitted to the UMP 110 by way of the mer
`chant. Upon receiving a payment type for a transaction
`between a consumer and a merchant, the UMP 110 collects
`payment information from the consumer based on the pay
`ment type selected by the consumer. Notably, identify theft is
`reduced since the merchant never has access to consumer
`payment information. The collected payment information is
`then used by a converter module 164 of the UMP 110 to
`complete the transaction.
`The converter module 164 generally acts as a “blackbox'
`that accepts messages in a first format, such as credit card
`0100 series messages, from the merchants 104 and translates
`them to a second format, such as debit card 0200 series
`messages, which payment processors can send to the various
`payment brand networks for routing to issuers. Further, the
`converter module 164 is authentication Solution agnostic, and
`it will launch the appropriate authentication Solution for each
`consumer based on the instructions of the issuer or payment
`brand network. For example, the converter module 164 can
`handle PIN based authentication or other types of authenti
`cation. Suitably, the converter module 164 performs the for
`going functions using a credentialing application launcher
`sub-module 166, a card alias vault sub-module 168, and a
`message mapping engine Sub-module 170, shown in FIG. 3.
`The credentialing application launcher sub-module 166
`generally determines both routing information for the trans
`action (i.e., the payment brand network to employ) and a
`credentialing application for the transaction. A credentialing
`application is an application used to collect credentials. Such
`as a PIN, from a consumer at the time each purchase or
`payment is initiated and is Suitably approved by a payment
`brand network or issuer. Credentialing applications for Accu
`lynk, HomeATM, MagTek, US Encode, Adaptive Payments,
`and Verient are contemplated. In certain embodiments, the
`determination is based on the provided payment information.
`For example, the determination may be made by using the
`card number of the payment information to perform a lookup
`in one or more bank identification number (BIN) tables, A
`BIN table contains the BINs eligible for routing to the pay
`ment brand networks 138 and indicates which credentialing
`application is to be used for each and which payment brand
`network each is to be routed to. Typically the BIN tables are
`stored in a database or memory, Such as a database 172, and
`provided by the payment processors 136.
`After determining the routing information and the creden
`tialing application for the transaction, the credentialing appli
`cation launcher Sub-module 166 runs the credentialing appli
`cation to acquire authentication data from the consumer.
`Authentication data is any data collected from the consumer
`deemed by the issuer of the payment instrument to be suffi
`cient to authenticate the consumer. Suitably, authentication
`data is acquired through coordination between the merchant
`and the UMP 110, where the consumer is presented with a
`graphical user interface prompting them to Submit the rel
`evant authentication data, such as a debit card PIN. For
`example, the merchant redirects the consumer to an authen
`tication page hosted by the UMP 110 over the communica
`tions network 112. As yet another example, the merchant
`
`30
`
`35
`
`40
`
`50
`
`60
`
`65
`
`Ex.1007
`APPLE INC. / Page 8 of 13
`
`

`

`7
`includes an iFrame in their graphical user interface pointing
`to a page hosted by the UMP 110 over the communications
`network 112.
`When the consumer submits the authentication data and
`the credentialing application receives the authentication data,
`the credentialing application processes the authentication
`data. Depending upon the determined credentialing applica
`tion, processing causes consumer authentication to occur at
`this point or the credentials to be formatted for authentication
`by the issuer of the payment instrument during authorization
`processing, discussed below. AS to the former, it is contem
`plated that the authentication data is Submit to, for example,
`the issuer for verification over the communications network
`112. The authentication data, optionally including authenti
`cation results, is then saved for Subsequent use in a database
`or a memory, Such as the database 172. As discussed herein
`after, this information will be appended to and/or substituted
`for data delivered in a credit authorization request message,
`such as a credit card 0100 message, that is received from an
`Internet acquiring platform of a payment processor, for inclu
`sion in a debit authorization request message. Such as a debit
`card 0200 message.
`Subsequent to receiving the authentication data, the card
`alias vault sub-module 168 may provide the merchant with an
`alias account number. For example, the card alias vault Sub
`module 168 may be adapted to generate a single use primary
`account number (PAN). Suitably, the card alias vault sub
`module 168 maintains a record of the relationship between
`the alias account number and the transaction and/or authen
`tication data in a database or memory, such as the database
`172. In that regard, the alias account number is suitably cor
`related with a real account number. The merchant then uses
`this alias account number in a credit authorization message.
`Suitably, the merchant generates the credit authorization mes
`sage using the alias account number and Submits the credit
`35
`authorization message to its Internet acquiring platform,
`optionally via a payment gateway. Based on the alias account
`number, the Internet acquiring platform routes the transaction
`to the message mapping engine Sub-module 170. For
`example, the transaction is routed to the UMP 110 using a
`BIN number (unique to the UMP 110) of the alias account
`number. As another example, the Internet acquiring platform
`can request the UMP 110 to identify the transaction as a debit
`transaction.
`Upon receiving the credit authorization message, the mes
`45
`sage mapping engine Sub-module 170 converts the credit
`authorization message to a debit authorization message for
`submission to the debit acquiring platform. The debit autho
`rization message Suitably includes the payment type for the
`transaction. To convert the credit authorization message, the
`message mapping engine Sub-module 170 merges and/or
`replaces data contained in the credit authorization message
`with the authentication data captured and delivered by the
`credentialing application launcher Sub-module 166 to create
`the debit authorization message. In certain embodiments, the
`message mapping engine Sub-module 170 also merges and/or
`replaces data contained in the credit authorization message
`with the routing information determined by the credentialing
`application launcher sub-module 166. The debit authoriza
`tion messages are Suitably tailored to the corresponding debit
`networks through which the debit authorization messages are
`to be routed. In certain embodiments, a rules engine may be
`employed to facilitate this tailoring. In that regard, debit net
`work specific rules for converting credit authorization mes
`sages to debit authorization messages may be stored in a
`database or memory, such as the database 172. Furthermore,
`the message mapping engine Sub-module 170 may accom
`
`55
`
`40
`
`50
`
`60
`
`65
`
`US 9,317,850 B2
`
`10
`
`15
`
`25
`
`30
`
`8
`modate e-commerce transaction types, such as delayed and
`recurring payments, that are not supported by the deb