(19) United States
`(12) Patent Application Publication (10) Pub. N0.2 US 2001/0032192 A1
`(43) Pub. Date:
`Oct. 18, 2001
`Putta et al.
`
`US 20010032192A1
`
`(54)
`
`METHOD AND APPARATUS FOR
`IMPROVED FINANCIAL INSTRUMENT
`PROCESSING
`
`(76) Inventors: Laxmiprassad Putta, Cambridge, MA
`(US); Sudhakar Durairaj, WatertoWn,
`MA (US); Sridhar Ramachandran,
`WatertoWn, MA (US); James Lowell
`Frankel, Lexington, MA (US)
`
`Correspondence Address:
`Ronald J. Kransdorf
`Wolf, Green?eld & Sacks, RC.
`600 Atlantic Avenue
`Boston, MA 02210 (US)
`
`(21)
`(22)
`
`Appl. No.:
`
`09/735,064
`
`Filed:
`
`Dec. 11, 2000
`
`Related US. Application Data
`
`(63) Non-provisional of provisional application No.
`60/170,031, ?led On Dec. 10, 1999.
`
`Publication Classi?cation
`
`(51) Int. Cl? .......................... .. G06F 17/60; H04K 1/00;
`H04L 9/00
`
`(52) US. Cl. ............... .. 705/76; 705/39; 705/65; 705/67;
`705/78
`
`(57)
`
`ABSTRACT
`
`A method and apparatus are provided for issuing secondary
`programmable account numbers (SPANs) to a customer or
`customer-designated party, each of Which SPANs is associ
`ated With a customer primary account or other ?nancial
`instrument, and each of Which SPANs has selected usage
`parameters assigned thereto. SPANs may be issued as a
`book, With usage parameters assigned to the book in addition
`to or instead of individual SPANs. When a SPAN is pre
`sented to a merchant for payment, the SPAN, including
`compliance With usage parameters, is veri?ed and appropri
`ate action taken based on either veri?cation or failure of
`veri?cation.
`
`Account Registration
`
`Is the cusiomer
`registered oniine?
`
`Yes i
`
`No
`
`Get the customers online
`[09m and password
`
`[——>
`NO
`
`Get me customers online
`iogin. password and 1
`registraucn information
`
`9 V
`
`Customer
`daiabase
`
`352
`
`is the login ID valid?
`
`Retrive customer's
`registration information
`from the primary account
`database
`
`Obtain
`Additional
`Information —
`Check for
`Validity.
`
`TWILIO, INC. EX. 1012
`Page 1
`
`

`
`Patent Application Publication Oct. 18, 2001 Sheet 1 0f 13
`
`US 2001/0032192 A1
`
`808359‘
`
`mciaocw
`
`6 J
`
`ww? $1
`
`w... w a
`mi. M m
`da
`w
`
`m m
`
`m . w +
`
`H. I. (\ldOQ "
`
`
`
`, .21 “3.0 F GE
`
`
`“23:33 . J QEmEEEmQE b E u n
`utu?oz “
`
`.......\J J! Ego m VI.)
`
`
`wfoznwz E3.
`226:5 1 m
`
`_ m “
`
`
`
`WwMmTBEH :owmom. m
`
`_
`
`mumtBE "
`
`k m
`
`n _
`
`TWILIO, INC. EX. 1012
`Page 2
`
`

`
`Patent Application Publication Oct. 18, 2001 Sheet 2 0f 13
`
`US 2001/0032192 A1
`
`mm,
`
`A- menmwwaux.
`
`
`
`..~ . wag,
`
`TWILIO, INC. EX. 1012
`Page 3
`
`

`
`Patent Application Publication Oct. 18, 2001 Sheet 3 0f 13
`
`US 2001/0032192 A1
`
`Account Registration
`
`Is the customer
`registered ontine?
`
`T
`
`Yes t
`
`Get the customer's onnne
`F’ togtn and password
`No
`
`Get the customers ontine
`togtn. password and
`registration information
`
`is the togtn ID vahd?
`
`ts the togtn i0
`availabie?
`
`Retrive customer's
`registration information
`from the primary account
`database
`
`Obtain
`'s‘ddmqnal
`In Ormatlon _
`Check for
`Validity.
`
`-—> Enable SPANs
`
`Stop
`
`FIG. 3
`
`TWILIO, INC. EX. 1012
`Page 4
`
`

`
`Patent Application Publication Oct. 18, 2001 Sheet 4 0f 13
`
`US 2001/0032192 A1
`
`Primary account
`
`P“ 101
`
`1:N
`
`SPAN
`
`‘H000
`
`Usage parameters
`
`Authorization conditions
`
`1
`'
`512
`
`1
`1
`511
`
`FIG. 4
`
`TWILIO, INC. EX. 1012
`Page 5
`
`

`
`Patent Application Publication Oct. 18, 2001 Sheet 5 0f 13
`
`US 2001/0032192 A1
`
`?uthorija?ln 2 congiiiions
`
`'
`
`511
`
`*
`
`'
`
`"
`
`Valid ciedit card number
`Valid merchant
`\
`Card not expired
`Primer} account has funds
`
`Mouiiiahil- (tondiiions c :1 c" "4r;
`512
`
`Usage Pzra'mei?YS
`
`Face value '1
`Duration-based limit _
`_
`Credit iirnii
`iuierchsntswho can acceptihe card '
`Valid date ofsal-z
`Veiocity, Number of uses
`Expiry dai-a set before primar/ expiry date
`Authentication information (name. zip, e26)
`Colleciiveresirictions
`---~
`
`FIG. 5
`
`TWILIO, INC. EX. 1012
`Page 6
`
`

`
`h t6 f 13
`~
`o
`.
`.
`Patent Appllcatlon Publlcatlon Oct. 18,2001 S ee
`
`US 2001/0032192 A1
`
`0 P
`
`- Q
`nmm moan!
`
`
`16:
`
`
`
`
` lxthu arnoun! ‘mm! In
`
` financial ndnoh
`320
`
`
`
`
`Una: gmrnclu
`Obhln
`dmbm
`
`Aulholuilon
`nlrmlmien
`cede
`
`Sand 'dmIcd'
`eod,o(520) and
`gonmlu
`
`through 1211
`mud lunmflon
`360
`
`munch! Mimk
`lo nqulvlng
`
`
`
` P"0€Q130!
`3¢nd aulhulzzllon
`
`
`soda through
`
`financial nflvvok
`
`to uqulring
`proomor
`
`Pdmny mount
`damm
`352
`
`Custonm
`pulmncn
`dmbm 355
`
`the primarymount
`
`
`
`Hula tundxln thu
`pnlnury accouni
`
`mm:
`lnnmtion
`
`
`
` Updm
`pmmlux on
`unqc mm cm
`
`
`
`
`
`
`
`
`
`
`Hallrym umomu
`
`
`(100/I01) through
`
`nolinmion lntufm
`(400)
`
`
`
`aqcnciuin lhu NC
`nt|~ok353
`
`Other Information
`357
`
`TWILIO, INC. EX. 1012
`Page 7
`
`TWILIO, INC. EX. 1012
`Page 7
`
`

`
`Patent Application Publication Oct. 18, 2001 Sheet 7 0f 13
`
`US 2001/0032192 A1
`
`
`
`2365 388:6
`
`ova
`
`
`
`338E a522
`
`30
`
`3£§+¢H D 2: :Q 0;
`
`9m
`
`3225230
`
`5:35.32
`
`3385
`
`$6
`
`
`
`13.06 333m
`
`own
`
`
`
`N @E a?
`
`‘
`
`263.50 inlllllll
`
`. _\
`
`
`
`82.35 “5:”:
`
`00» 18830
`
`
`
`
`230823 3322.
`“523 30:28.3
`
`“I “3
`
`\]!j
`
`.
`
`.
`
`:6...
`
`m 08
`
`TWILIO, INC. EX. 1012
`Page 8
`
`

`
`Patent Application Publication Oct. 18, 2001 Sheet 8 0f 13
`
`US 2001/003219
`2 A1
`
`'
`i
`Modi?cation ' odure 342
`
`Oalabanxiif?
`
`Pdmary account
`600
`
`MM cuxiomnlonin
`and pammld valid?
`'
`
`Y"
`+
`Obtain profmnm fmn
`cummuprmnnw
`database an! the“ not by
`RM cumnju ml
`
`“ SPAN *
`S
`"1 \ da-ia-mé 8
`35'
`-
`’
`
`"*‘->- Primary account
`
`dahhan \éii
`
`I
`"
`
`NC nalncrk
`lnhdan
`000
`
`k
`
`'
`
`.1
`
`-
`
`*'°
`
`4'}- Authorization
`paumchl
`. dalabau 353 J
`
`I
`
`‘ ,
`
`Obtain am madi?oallona
`uquutad In aulhorizah‘cn
`
`paramalu
`
`I
`Nolify
`custom:
`M about
`
`Invalid
`loqln
`
`A
`
`_‘
`
`“Nam.
`dalabaaa
`\m-av/
`
`,
`
`4% Custom"
`pramancu
`“I'M” 355
`
`'1’
`
`a the modmuh'ona val:
`forth. primary account and
`
`sauna"; and?
`
`"my custom"
`lnconslsien
`mu: m
`q
`
`_
`
`Y"
`Y
`Modify
`aulhmizauon
`pamnm!
`
`CPU
`
`Y“
`
`4% Usagq palanulu
`“3121"
`W
`
`"i-
`
`Oataban cl
`agcnclu In In: NC
`net-wk 358
`
`* Olhu lnfolmah'on
`359
`
`\
`
`Clad‘
`
`N
`
`TWILIO, INC. EX. 1012
`Page 9
`
`

`
`,
`-
`.
`.
`.
`Patent Appllcatlon Publlcatlon Oct 13,
`
`2001 Sheet 9 of 13
`
`US 2001/00321
`
`92 A1
`
` Prlmuymoun!
` Issuing lnlutm
`
`curtomcfi
`
`Pm:-.2
`‘t N xsuni tothlx
`
`,
`
`«mm '
`
`700
`
`
`
`
`
`Initialize
`ymmclus on
`mac.
`lunmh'on:. «Io
`
`
`
`
`
` Flodlndm.-siomnte
`
`
`movmlcxuon module pmlng
`
`IM dmutt wmmn
`pufmnm and crlmlool
`pulmnm
`
`ucncies In the NC
`nc1wok358
`
`
`
` .,,....gpa -,;~o» .-..
`
`flu cuxlomu on J spuclfiod
`olflu thwugh the Issuing
` Olhtl’ Inmmaflon
`lnmfm
`
`
`
`FIG. 9
`
`359
`
`TWILIO, INC. EX. 1012
`Page 10
`
`TWILIO, INC. EX. 1012
`Page 10
`
`

`
`Patent Application Publication Oct. 18, 2001 Sheet 10 0f 13
`
`US 2001/0032192 A1
`
`37)O
`Programmable Account Number Generator
`
`Get the account range start
`and end for programmable
`account numbers
`
`SPAN
`database
`
`351
`
`Get a random number R <—_1
`
`Set X to
`start + R mod (end - start)
`
`Is a checkdigit
`required?
`
`Set the checkdigit in X to
`the computed checksum
`
`ts the
`account X active
`in database
`
`Yes
`
`Activate the
`account in the
`SPAN Database
`
`s the request for
`account ontine'?
`
`Yes
`
`Return the account
`numberX
`
`Enqueue X to the queue of
`available programmable
`accounts
`
`FIG. 10
`
`TWILIO, INC. EX. 1012
`Page 11
`
`

`
`Patent Application Publication Oct. 18, 2001 Sheet 11 of 13
`
`US 2001/0032192 A1
`
`
`
`flauofioo.>om
`
`mvm
`
`.r42$».oc_.e:.oEB:_:R.
`
`uocncficfie:Sooo<
`
`
`
`cozuoavuEeovao
`
`
`
`
`3.2.2cozaaoxmnewno.2...
`
`.:._:.:..%aEoE£2uo:.o__am
`
`
`
`flzmo«€20«mo...
`
`ucznzoauz
`
`ncozqooxa
`
`
`
`_:::__oa_§._n_o=mc_.._
`
`
`
`U23«.:£o;E
`
`mcoE_o_....
`
`I-
`O
`05
`C’
`Cu-.
`G4-
`
`E.
`
`CQ3Oé
`
`
`
`.33..uc:ooo<
`
`_m=o=uno>coo
`
`=o=oE£.c_
`
`TWILIO, INC. EX. 1012
`Page 12
`
`TWILIO, INC. EX. 1012
`Page 12
`
`
`
`
`
`

`
`Patent Application Publication Oct. 18, 2001 Sheet 12 0f 13
`
`US 2001/0032192 A1
`
`c2835;
`
`3323
`
`hnm
`
`$25
`
`$5
`
`“.3222
`
`3m v2.02
`
`
`
`
`:28 ~23 :llv.
`
`Now»;
`
`5:63: a:
`
`NF .GE
`
`
`
`32:8: 220:3
`
`£253:
`
`00m
`
`con
`
`
`
`“.53: 235i
`
`TWILIO, INC. EX. 1012
`Page 13
`
`

`
`Patent Application Publication Oct. 18, 2001 Sheet 13 of 13
`
`US 2001/0032192 A1
`
`Single purchase authorization
`
`Is this the ?rst
`authorization?
`
`is
`the time of
`transaction same as
`first authorizaton
`No.
`
`the total auth
`amount within face value or
`preauthorized
`amgunt
`
`No
`
`is customer
`information different
`from ?rst auth?
`
`No
`
`Is
`the merchant
`fraud prone
`?
`
`No
`
`is
`the merchant
`different from the
`
`firstvauth
`
`No
`
`Con?gurable to
`Auth/Deny
`
`Customer
`database
`
`351
`
`FIG. 13
`
`TWILIO, INC. EX. 1012
`Page 14
`
`

`
`US 2001/0032192 A1
`
`Oct. 18, 2001
`
`METHOD AND APPARATUS FOR IMPROVED
`FINANCIAL INSTRUMENT PROCESSING
`
`RELATED APPLICATION
`
`[0001] This application claims priority from Provisional
`Application Ser. No. 60/170,031, ?led Dec. 10, 1999
`
`FIELD OF THE INVENTION
`
`[0002] This invention relates to transaction processing of
`?nancial instruments such as credit cards, and more speci?
`cally to methods and apparatus for improving the security,
`?exibility and privacy of such transactions.
`
`BACKGROUND OF THE INVENTION
`
`[0003] Since the inception of credit cards, limits have been
`set on their usage. Credit card issuing institutions place
`limits on credit cards typically to reduce overuse thereof.
`
`[0004] For example, credit cards generally have a credit
`limit set on them. Purchases made over the credit limit Will
`not be accepted by the credit card issuing institution. Simi
`larly an expiry date can be set on a credit card to limit its
`validity. With the Widespread deployment of netWorks to
`perform credit card processing, the use of terminal point
`of-sale devices to perform credit card authoriZations has
`become common. Today, credit card payments are ?rst
`authoriZed and later charged after the goods are shipped.
`[0005] Credit card issuing institutions offer ?exibility to
`customers in establishing their credit card parameters, such
`as the account to be charged and monthly spending limits.
`For example, corporate credit cards offer the ?exibility of
`charging payments made on a secondary credit card to its
`primary (master) credit card account. Multiple secondary
`credit cards can be issued on a primary credit card. More
`over, the oWner of the primary credit card can impose
`constraints on the usage of the secondary credit cards, such
`as setting the monthly credit limit. The use of such cards is
`Widespread in businesses and families.
`
`[0006] Customers can make credit card payments even if
`the credit card is not physically presented to the merchant.
`Orders can be placed by telephone or mail, and payments
`can be made using the credit card number, along With
`authentication information such as expiration date, card
`holder name as it appears on the card, billing address and in
`some cases CVV2 number. With the recent boom in online
`retailing, more customers use credit cards in such “card-not
`present” transactions.
`
`[0007] HoWever, credit card payments over the Internet
`are susceptible to risk of fraud. For transactions Where the
`customer physically presents the card at the point-of-sale,
`the merchant can authenticate that the card belongs to the
`customer presenting the card (for example, by comparing a
`signature to the signature on the card, by comparing the
`person presenting the credit card to a photograph on the
`card, or by asking for additional identi?cation). But, for
`“card-not-present” transactions, the only Way of authenti
`cating is by checking that the authentication information
`provided by the customer is correct. Though this authenti
`cation mechanism is often acceptable, it’s by no means
`adequate. If a malicious agent manages to acquire the card
`number and the authentication information, then he can
`commit fraud very easily. The card number and authentica
`
`tion information can very easily be obtained by breaking
`into the merchant databases. There are knoWn instances of
`such break-ins. The cardholder Will not be able to detect this
`fraud until he receives his monthly statement. Then the
`cardholder has to go through the hassle of disputing the
`transaction.
`
`[0008] In another malicious scenario, the merchant can
`overcharge the card. In a “cardnot-present” transaction, the
`customer has no control over the amount the merchant is
`charging. A fraudulent merchant can very easily overcharge
`the card or even charge the account tWice (double charge).
`
`[0009] In another scenario, if the customer gives his card
`for recurring payments such as to pay an ISP, to pay for
`phone service, or to pay for neWspaper or magaZine sub
`scriptions, the service provider can charge the card on a
`periodic basis. If the customer cancels the service there is a
`risk that the service provider’s billing systems are not
`updated on time and the customer’s card is charged. In this
`instance the cardholder has to recogniZe that it’s an unau
`thoriZed charge and dispute the transaction With either the
`service provider or the issuing bank.
`
`[0010] Many customers are uncomfortable making pur
`chases online because of the above and other reasons. Online
`shops may not succeed because of the reluctance of neW
`customers to buy online.
`
`[0011] Credit card institutions have been promoting the
`use of credit cards by protecting the customers from fraud.
`In the USA, for example, the liability in case of fraud is
`limited to $50 if the customer reports the case of fraud
`properly. Although such protection improves credit card
`usage, the institutions need to bear the fraudulent charges
`made or pass them on to the merchant. Customers, on the
`other hand, need to be aWare of the risk of fraudulent
`charging and must look at their monthly statements With
`care.
`
`[0012] There have been many attempts to overcome the
`problem of credit card fraud for “card-not-present” transac
`tions.
`
`[0013] One of the notable developments is the Secure
`Electronic Transaction (SET) protocol created by Well
`knoWn technology and credit card institutions. This protocol
`Was developed to address the security issues of “card-not
`present” transactions conducted over the Internet. It involves
`the card issuing bank, the customer and the merchant and
`provides a detailed protocol for encryption of data and
`identi?cation and certi?cation of various parties. It’s Well
`published by the credit card institutions, but due to the
`investment required by the merchants, adoption has been
`limited.
`
`[0014] Another method being populariZed by a number of
`credit card institutions are smart cards. Smart cards are
`credit cards With an embedded chip Which can hold infor
`mation about the cardholder. They implement different types
`of request-response and encryption schemes to ensure secu
`rity. US. Pat. No. 5,317,636 (ViZcaino) explains hoW a
`typical smart card system Works. Smart cards require a
`special reading device so that the information stored on the
`chip can be interpreted. This Would mean changes to the
`existing point-of-sale (POS) terminals, Which could be very
`costly, and can be of limited value for Internet or other
`card-not-present transactions.
`
`TWILIO, INC. EX. 1012
`Page 15
`
`

`
`US 2001/0032192 A1
`
`Oct. 18, 2001
`
`[0015] Another method is to use a system such as Digi
`Cash, US. Pat. No. 5,712,913 (David Chaum), Where the
`information is split between various parties, so that no one
`database can be hacked to gain access to all the information
`required to commit fraud.
`[0016] Various approaches have been developed to control
`the use of the card, thereby making the card more secure.
`Japanese Patent No. Hei 6-282556 describes a system in
`Which a credit card number can be used only once and in
`Which personal information and use limits are recorded on
`the card. Aspecial card-reading device reads the information
`from the card and checks if the usage conditions permit the
`card to be used. The card information Will be transferred to
`the issuing institution only if the use conditions are valid.
`This system Would again require changes to the existing
`POS terminals.
`
`[0017] Other approaches Were developed to use proxy
`numbers instead of the actual credit card to do online
`transactions for example, US. Pat. No. 6,000,832, US. Pat.
`No. 5,833,816 (Franklin et al.). This system assumes cre
`ation of an electronic commerce card that is maintained for
`the customer at the bank. This online commerce card is
`assigned a real customer account number at the bank. When
`the customer Wants to conduct an online transaction, the
`customer requests a transaction number from the bank. This
`transaction number is given to the merchant. When the
`merchant presents the number to the bank, the bank identi
`?es that the number is a proxy for an online commerce card
`and charges the transaction to the real account number. This
`number is valid for only one transaction. This is a good
`system to control fraud, but a good number of Internet
`purchases are shipped separately. In this case, the present
`system Will deny the second authoriZation because it relates
`to a separate transaction.
`
`[0018] While security is a major concern in the use of
`credit cards, particularly on the Internet, there are also other
`concerns With the current systems. One major concern is
`privacy, credit card transactions by an individual being
`utiliZed by merchants and others to build up a pro?le on the
`individual Which is used for marketing and other purposes.
`Privacy concerns are a factor limiting more extensive use of
`credit cards in connection With E-commerce and thus in
`limiting the expansion of E-commerce.
`
`[0019] Further, While existing credit cards offer some
`?exibility, as indicated above, in use of credit cards, the
`?exibility and control afforded to a user in the use of credit
`card accounts While maintaining security and privacy, is still
`fairly limited. Greater ?exibility is for example desirable in
`being able to control duration and credit/spending limits on
`a card, merchants With Whom the card can or cannot be used,
`number of uses, use velocity and many other factors. Fur
`ther, While credit card numbers are required for many types
`of transactions, including most E-commerce transactions,
`credit cards are not readily available in some parts of the
`World or to some individuals. A capability of being able to
`conduct credit card-like transactions, Which may be trans
`parent to the merchant, from a bank checking account,
`savings account, or other ?nancial instrument is therefore
`also highly desirable.
`
`[0020] Finally, there is a huge investment in existing POS
`terminals and in existing systems for processing credit card
`transactions. Therefore, any improvements required to
`
`address the above security, privacy, ?exibility and other
`concerns should require minimum changes in existing ter
`minals/systems both to minimiZe implementations, costs and
`to facilitate rapid implementations.
`
`[0021] Therefore, a need exists for more secure, private
`and ?exible methods of processing transactions and pay
`ments based on existing credit card processing infrastructure
`While requiring minimal changes thereto.
`
`SUMMARY OF THE INVENTION
`
`[0022] In accordance With the above, this invention pro
`vides a system and method for facilitating access to ?nancial
`instruments such as credit and debit card accounts, checking
`accounts, bank accounts and the like. Secondary program
`mable account numbers (SPANs) are issued in response to
`veri?ed customer requests, veri?cation of a customer
`request being provided for example by a veri?cation mod
`ule. Each SPAN is associated With at least one customer
`?nancial instrument, and each span has usage parameters
`assigned thereto. When a SPAN is presented to a party for
`payment, an authoriZation module receives request for
`authoriZation from such party. Such module may authenti
`cate the SPAN verify that usage parameters for the SPAN
`have been complied With, deny authoriZation if the SPAN is
`not authenticated or if usage parameters for the SPAN are
`not complied With, and, if the SPAN is authenticated and
`usage parameters are complied With, update usage param
`eters based on the authoriZation request, update the associ
`ated customer primary account/?nancial instrument and
`send an authoriZation output.
`
`[0023] More speci?cation, the invention provides a mod
`ule for issuing secondary programmable account numbers
`(SPAN s) to a customer, Which module includes a veri?cation
`module Which receives SPAN requests and veri?es the
`validity of such requests; a generating module operative in
`response to a veri?ed SPAN request for providing at least
`one SPAN, each SPAN being associated With at least one
`customer primary account/?nancial instrument; a usage
`module assigning usage parameters to the SPANs; and an
`issuing module Which issues each SPAN to a customer
`speci?ed party, the issued SPAN being usable only Within
`the assigned usage parameters. The invention also includes
`a method for issuing SPANs to a customer Which includes
`the customer inputting a SPAN request to an issuing system;
`the system verifying at least one of the customer and the
`request; the system providing at least one SPAN in response
`to a veri?ed SPAN request, each SPAN being associated
`With a selected customer primary account/?nancial instru
`ment; the system assigning usage parameters to the SPANs;
`and the system issuing each SPAN to a customer speci?ed
`party, the issued SPAN being usable by such party only
`Within the assigned usage parameters. Either the module or
`method may include a memory storing preferred usage
`parameters for the customer, Which preferred usage param
`eters are used as default usage parameters for each SPAN for
`the customer. Each SPAN request may also include at least
`one usage parameter, the at least one usage parameter of the
`request being assigned to the corresponding SPAN in lieu of
`the corresponding preferred usage parameter. Where no
`preferred usage parameters are provided, the usage param
`eters included With the SPAN request are utiliZed as assigned
`usage parameters. Usage parameters can include, but not are
`not limited to, at least tWo of SPAN duration, SPAN face
`
`TWILIO, INC. EX. 1012
`Page 16
`
`

`
`US 2001/0032192 A1
`
`Oct. 18, 2001
`
`value, SPAN credit limit, permitted merchants, excluded
`merchants, value velocity, use velocity, period of use, and
`number of uses for the SPAN. A mechanism may be pro
`vided for altering at least one of the usage parameters after
`the SPAN has issued in response to a request from the
`customer and/or the party to Whom the SPAN is issued.
`
`[0024] At least selected SPANs may be issued to a third
`party designated by the customer. The customer may also
`have a plurality of primary accounts or other ?nancial
`instruments, a mechanism being provided for selecting the
`?nancial instrument With Which each SPAN is associated.
`For some embodiments, the ?nancial instrument selected for
`each generated SPAN is the same as the instrument selected
`for the previously generated SPAN unless the customer
`otherWise indicates, for example in the SPAN request. The
`?nancial instrument selected for a SPAN can also be
`changed by the customer after the SPAN has issued.
`
`[0025] For some embodiments, a plurality of acceptable
`SPANs are generated and stored. When a SPAN request is
`received, at least one SPAN is then provided from the stored
`acceptable SPANs. A magstripe Writing device may also be
`provided, the Writing device recording a SPAN to be issued
`on a magstripe of a suitable token. Aplurality of SPAN s may
`also be provided and issued as for example a book to Which
`the usage parameters are assigned. At least one usage
`parameter may be assigned to each book, each SPAN in the
`book being usable so long as the cumulative use of the
`SPANs for the book do not exceed any usage parameter
`assigned to the book. HoWever, usage parameters may be
`assigned to each SPAN of the book in addition to the usage
`parameters assigned to the book.
`
`[0026] A SPAN may be usable to access funds from a
`customer selected ?nancial instrument, for example a cus
`tomer checking account. A SPAN assigned to a check and
`may be usable as a check also as a credit card number.
`Where ?nancial netWorks having given protocols utiliZe the
`module and method of this invention, a bridge may be
`included permitting use of SPANs across such ?nancial
`netWorks.
`
`[0027] One usage parameter may be SPAN duration, a
`SPAN normally remaining viable for its assigned duration.
`A customer may be provided With the ability after a SPAN
`is issued to change its assigned duration. Time durations for
`SPANs may be set in relatively small time intervals, for
`example time intervals not exceeding days. The system may
`also detect the issuance of an excessive number of SPAN s to
`a customer during a given time interval and/or an unusual
`pattern of SPAN s request for a customer, and the system may
`at least terminate the issuing of neW SPAN s for the customer
`in response to such detection.
`
`[0028] The invention may also include an authoriZation
`module Which receives request for authoriZation from a
`party to Whom a SPAN, issued as indicated above, has been
`presented for payment, the module authenticating the SPAN,
`verifying that usage parameters for the SPAN have been
`complied With, denying authoriZation if it cannot authenti
`cate the SPAN or if usage parameters for the SPAN are not
`complied With and, if the SPAN is authenticated and usage
`parameters met, updating usage parameters based on the
`authoriZation request, updating the associated customer
`?nancial instrument and sending an authentication output.
`Similarly, the invention includes a method for authenticating
`
`requests for authoriZation from a party to Whom a SPAN,
`issued as described above, is presented for payment, Which
`method includes: authenticating the SPAN, verifying that
`usage parameters for the SPAN have been complied With,
`denying authoriZation of the SPAN is not authenticated or if
`usage parameters for the SPAN are not complied With, and,
`if this SPAN is authenticated and usage parameters are
`complied With,
`updating usage parameters based on the
`authoriZation request, (ii) updating the associated customer
`primary account, and (iii) sending an authoriZation output.
`
`[0029] Either the authoriZation module or method may
`involve the person authoriZed to use a SPAN having a token
`Which facilitates identi?cation of the person from a remote
`site, the authoriZation module or system receiving informa
`tion from the token and utiliZing such information to verify
`that the party is authoriZed to use the SPAN for the received
`request. The token may be a dongle, a card With a magstripe
`or a device generating a time varying value Which is
`substantially unique to an individual at each time interval.
`For some embodiments, once a SPAN is presented for
`payment to a given party, the authoriZation module permits
`such SPAN to be used thereafter only for payments to such
`party. A usage parameter may be the number of times a
`SPAN may be used, some embodiments treating all items
`ordered together on a SPAN as a single use, even if the items
`are shipped and/or invoiced separately. For some embodi
`ments, the identity of the party to Whom the SPAN is issued
`is not revealed to the party to Whom the SPAN is presented
`for payment and is not required either as an input or an
`output from an authentication module. One option Would be
`to provide a pseudo identity for the person using the SPAN
`to the merchant or other party to Whom the SPAN is
`presented for payment. The authoriZation module and/or
`method preferable includes at least one fraud detection
`mechanism. For example, an unusual pattern of authoriZa
`tion requests from a party requesting such authoriZations
`and/or an unusual pattern of use for SPANs previously
`received by such party may serve as an indication of
`potential fraud. At least noti?cation to a customer over
`appropriate media may be provided of at least any suspi
`cious authoriZation request for a SPAN issued at the request
`of such customer. Where there are fraud detection programs
`in effect for the primary account/?nancial instrument, use of
`such programs may be facilitated by mapping SPANs to the
`corresponding ?nancial instrument for such programs. A
`plurality of purses may also be provided for at least selected
`SPANs, each purse being for a different category of pay
`ments, each received authoriZation request for a SPAN being
`allocated to the appropriate purse.
`
`[0030] The foregoing and other objects features and
`advantages of the invention Will be apparent from the
`folloWing more particular description of a preferred embodi
`ment of the invention as illustrated in the accompanying
`draWings, the same reference numeral being utiliZed for
`common elements in the various ?gures.
`
`IN THE DRAWINGS
`
`[0031] FIG. 1 is a schematic representation of an illustra
`tive embodiment integrated With ?nancial netWorks.
`
`[0032] FIG. 2 is a How diagram of the authoriZation
`process that occurs When a SPAN is used in credit/debit
`transaction.
`
`TWILIO, INC. EX. 1012
`Page 17
`
`

`
`US 2001/0032192 A1
`
`Oct. 18, 2001
`
`[0033] FIG. 3 is a How diagram of the account registration
`process.
`[0034] FIG. 4 is a How diagram showing the relationship
`betWeen a primary account and SPANs.
`
`[0035] FIG. 5 is a diagram of modi?able and non-modi
`?able authorization parameters.
`[0036]
`process.
`
`FIG. 6 is a How diagram of the authoriZation
`
`[0037] FIG. 7 is a diagram of the customer module and
`associated tools.
`
`[0038] FIG. 8 is a How diagram of authoriZation param
`eters modi?cation process.
`
`FIG. 10 is a How diagram of SPAN-generation
`
`[0039] FIG. 9 is a How diagram of a SPAN-issuing
`process.
`[0040]
`process.
`[0041]
`[0042] FIG. 12 is a diagram of the integration of different
`payment methods.
`[0043] FIG. 13 is a How diagram of the single purchase
`authoriZation.
`
`FIG. 11 is a diagram of the service module.
`
`DETAILED DESCRIPTION
`
`[0044] With reference to the ?gures, an illustrative
`embodiment of the current invention is noW described. FIG.
`1 is a schematic representation of the illustrative embodi
`ment 30 of the invention integrated With ?nancial netWorks
`320 and communication interfaces 55. The illustrative
`embodiment 30 includes payment sWitches 305, program
`mable payments module 300 and an online interface 50. As
`used in this application, a module may be a softWare
`program or a hardWare module or a combination of the tWo.
`Programmable payment module 300 may include a netWork
`of service providers, such as ?nancial institutions, internet
`services providers, money management softWare providers
`and other organiZations Which provide support for the pro
`grammable payment module and its databases. In the illus
`trative embodiment, programmable payments module 300 is
`implemented as a stand-alone softWare program running on
`several computers, each containing at least one processor, a
`memory cache, at least a primary memory element and at
`least one memory disk. Online interface 50 is implemented
`as a softWare module that is integrated With a softWare Web
`server (not shoWn) serving Web pages to customers 100.
`
`[0045] Payment sWitches 305 interface to standard or
`proprietary ?nancial netWorks 320. Those netWorks may
`include credit/debit card netWorks, clearing houses and other
`private or public netWorks. Financial netWorks 320 are
`accessed When an authoriZation process for SPAN (see FIG.
`6) requires authoriZation from an institution that issued a
`particular primary ?nancial instrument.
`[0046] A customer 100 (see FIG. 2) has a single primary
`account located on a primary accounts database 352 (see
`FIG. 6) Within the programmable payments module 300.
`Customers 100 must register at least one primary ?nancial
`instrument With their accounts. A primary ?nancial instru
`ment may be a credit or debit card, a checking account, a
`savings account or other ?nancial instruments that alloW
`
`customers to draW funds on them. Programmable payments
`module 300 is operative to issue Secondary Payment
`Authentication Numbers (SPANs) to registered customers
`upon their request (see FIG. 9). Each SPAN is associated
`With a primary ?nancial instrument of customer chosen from
`a set of primary ?nancial instruments registered With pri
`mary account 101 (see FIG. 4). Customer 100 can associate
`more than one SPAN With any ?nancial instrument. Charges
`made on SPANs are made to the corresponding ?nancial
`instrument. Alternatively, a SPAN can have a stored mon
`etary value physically stored on it or associated With it in for
`eXample programmable payme