(19) United States
`a2) Patent Application Publication co) Pub. No.: US 2011/0066550 Al
`
` Shanketal. (43) Pub. Date: Mar. 17, 2011
`
`
`US 20110066550A1
`
`(54) SYSTEM AND METHOD FOR A SECURE
`FUNDS TRANSFER
`
`(52) U.S.Cwo. 705/43, 705/44; 701/300; 701/213;
`455/41.2; 455/41.1; 455/466
`
`(76)
`
`Inventors:
`
`(21) Appl. No.:
`
`Clinton L. Shank, Dallas, TX
`(US); MarkA. Brousseau, York,
`PA (US)
`12/560,750
`
`(57)
`
`ABSTRACT
`
`(22)
`
`Filed:
`
`Sep. 16, 2009
`Publication
`Classificati
`uiblea tion
`*lassiiica tion
`
`(51)
`
`Int. Cl.
`G06Q 40/00
`G06Q 20/00
`GOIC 21/00
`HO4B 7/00
`HO4B 5/00
`HO4W4/00
`
`(2006.01)
`(2006.01)
`(2006.01)
`(2006.01)
`(2006.01)
`(2009.01)
`
`According to one embodiment, a gatewayreccivesa transac-
`tion from a first device in local communication with a second
`device. The transaction includes a payment amount and a
`plurality of authorization codes. The gatewayuses the autho-
`rization codesto authorize the transaction andto determine an
`account for each device. The gateway then instructs an
`account manager to withdraw the payment amount fromthe
`accountofthe first device and to deposit it into the account of
`the second device. A result is received at the gateway, and the
`gateway sendsthe result to each device.
`
`
`
`
`
`21077
`21274
`
`F
`
`2147
`a6
`
`SEND ACTIVEBILLS
`_
`ACCEPT BILL
`SEND "PAY TO"INFORMATION
`
`OPEN CONNECTION
`990
`"
`
`218
`OPEN
`CONNECTION _/
`
`PAYMENT TRANSACTION
`INFORMATION
`“——*}_
`
`_
`
`PAYMENT
`TRANSACTION 224
`INFORMATION
`
`RESULT
`
`op
`
`222
`
`230
`NOTIFICATION
`232
` NOTIFICATICN AND
`\_AND KEY UPDATE
`
`LS KEY UPDATE
`
`.
`
`347]
`
`RELEASE
`
`RELEASE
`
`238
`S
`
`RELEASE
`
`:
`
`236
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 1 of 20
`
`
`
`12a~J
`payING DEVICE
`(AY Gateway]
`16a~J
`paying BANK
`16b
`BILLING DEVICE}7125
`202b
`LOGIN
`
`
`
`206
`____ BROADCASTDEVICE ID 7 _
`
`|. ____ACGEPTDEVICEID
`ESTABLISH PEER-TO-PEER CONNECTION
`
`208 “|
`
`||
`
`200
`“
`
`!
`
`.
`|
`
`
`
`PAYMENT
`
`226
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 1 of 20
`
`

`

`Patent Application Publication Mar. 17,2011 Sheet 1 of 10
`
`US 2011/0066550 Al
`
`
`
`
`
`
`
`
`BILLER'S BANK
`
`PAYER'S BANK
`
`FIG. 1
`
` ELECTRONIC
`(ACH) OR CHECK
`
`
`INTERFACE
`
`LOGIC
`
`PROCESSOR
`4
`
`40
`
`APPLICATIONS
`
`MEMORY
`34
`
`FIG. 2
`
`
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 2 of 20
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 2 of 20
`
`

`

`Patent Application Publication
`
`Mar. 17, 2011 Sheet 2 of 10
`
`US 2011/0066550 Al
`
` ‘OS-lwpg77OUYos-tuoo>09sjualukeddéd
`
`
`
`
`
`SyLaty[De
`
`GFDlaVEOlt
`
`
`
`
`
`sayopcr)YasvasGZdo]saodajo9|pasnlee4
`BS9S\2euSMAIABYOSG**¥KXBy‘OuU]
`
`cg“ureJBoidJNOJOJaquialuBaqJSNu
`.SaShf3©»4SelX&
`
`
`OARY[SNLSAUOYdI}90Buy“SauOYd||a9
`
`
`yeu]SHUGSU}LOJSI|[BledBs}MO|ag
`
`
`yuegJno,"$sao9oRGaNpurYyyoolLan|g
`UlyuRGJNOAa9sUODNOAJ]“WweiBo2d
`
`
`
`Jo}AUjIgeay)sap|AoidswaLWAeYd2Zd
`
`
`JayBuisnsayjoueAed0}uosisdauo
`
`
`JSOWOU}10}al|SgemINOaas‘JsI{SIU)
`WY£66WY£8:6
`
`“syuegHulyedialpedJo4Si}juan
`
`JnoulBuled|opedAjuaunsae
`
`0S
`
`aoueul4
`
`
`
`
`
`sejopdayasoas¢¢doysaedajog]paimes4©»4’SlX
`
`aaa2D°3oO
`
`Oo
`
`LLaSs
`
`i®2>Oo
`
`S©°°o
`SoN—°©®D©oO—ai°Oo
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 3 of 20
`
`
`
`
`
`
`
`

`

`Patent Application Publication
`
`Mar. 17, 2011 Sheet 3 of 10
`
`US 2011/0066550 Al
`
`
`
`OJu]19SF}
`
`
`
`
`
`
`Olu]Jassy|nejaqs]unoooy
`jo|=<?
`
`
`3G[JIM[eyeUy“a}!SqemJNOoO}paplewio]
`
`
`
`yeaseNOAaduQ“uOTeo|ddestu]Jalsi6a1
`
`POCOEON‘IHladeyg:clzayers“AO
`
`
`
`UOIJBANDBAu]Ja]Ua‘SSeppeaaogeau}
`
`UBLAIUOD[fmTeyATOYSNOA0}JUSS
`
`
`0}pasu[JIMNOAyeuAayVONPBAIE
`CLL#UlEWSLL:SSOIPpY
`jouye@ssouelj]BeBwoH
`
`
`UISqSELUCHBUUOJU!JaR}UODINO,
`d&Dla
`
`saouel4aor“OWEN
`NV00°69¢Lely[fo
`pS2i-prez-ecav—:ABy
`KKHKH‘PJOMSSeq
`saedsuyulAdy
`02xxxxxABJUF-OY
`
`
`
`
`
`
`
`
`
`
`gja|dwoaaseald‘sesodinduonuanaid
`
`Ssa0Uel4dof
`
`
`
`ZLL#UIENGEZL‘SSBIPpYy
`
`
`
`OJU]Jasf)
`
`NY00:6geLely[go
`
`
`
`
`
`VOZOEON‘IIHIadeyg:017ayels“AUD
`
`
`
`
`
`jeuye@saauel!‘[fe\AjaSUH
`
`
`
`
`
`dais‘sseaoidomyBS}VOLeusiBaydays
`
`nxnxPIOMSS4
`
`
`
`
`
`paljddnsNodUONeWJOJU!BY]SIBATAPBUG
`
`
`
`
`
`pnedyJO4‘NOA0}Jussaq0}A8yUONRAIIE
`
`
`
`UBUNMjle\\9UeSayesauadpuesnOo}
`
`
`
`“gaogeusaihssauppeay]jeom,days
`
`aaa2D°3oO
`
`LLa>Oo
`
`i®2>Oo
`
`S©°°o
`SoN—°s®D©oO—ai°Oo
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 4 of 20
`
`
`
`
`

`

`Patent Application Publication
`
`Mar. 17, 2011 Sheet 4 of 10
`
`US 2011/0066550 Al
`
`Bupyjoay9
`
`
`
`WY00:6geLely[poe
`
`SJUNODDY
`
`PIGBLISVES|HfUNOIDY
`
`Séc00001!“7yueg
`
`RKKKMHK:PJOMSSE|
`
`yuegJNOAolulfo7q
`
`HRKKKK
`‘PUOMSSE
`
`
`
`
`
`
`
`
`
`EERE“uI607
`INNODOVwoo:—9eLet[fl
`QO}MAN
`
`
`
`
`
`
`
`
`
`
`AdAL
`
`:eae
`
`paid40aur]
`
`Oulysey9
`
`SBulAes
`
`
`
`Wpasds[lqcw
`
`PegWe!
`
`
`
`aaa2D°3oO
`
`Oo
`
`LLaSs
`
`i®2>Oo
`
`S©°°o
`SoN—°ifs)®D©oO—ai°Oo
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 5 of 20
`
`
`
`
`

`

`Patent Application Publication
`
`Mar. 17, 2011 Sheet 5 of 10
`
`US 2011/0066550 Al
`
`Suit
`
`WY00:5
`9¢1g.{oe
`
`WY00:6neLaiv[go
`
`syineyaqBullig
`
`
`
`
`
`
`
` BuseyG)ISYHO Junosoy
`
`
`
`
`
`
`
`
`dmesg—AuoysH_—igBAg|BULLI
`
`
`
`
`
`
`
`
`
`
`OJuyJ3S/)synejaqsyunoaoy
`(jzce,
`
`
`cerLl
`#|a
`
`
`
`
`
`
`
`
`DEDl
`
`
`
`aaa2D°3oO
`
`Oo
`
`LLaSs
`
`i®2>Oo
`
`S©°°o
`SoN—°©®D©oO—ai°Oo
`
`<auour>04
`
`
`
`synejagjuawAed
`
`
`
`
`
`Buyygay)@3SvH9junosoy
`
`
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 6 of 20
`
`
`
`
`

`

`Patent Application Publication
`
`Mar. 17, 2011 Sheet 6 of 10
`
`US 2011/0066550 Al
`
`
`
`LNAWAVd
`
`
`
`74ge2_|.+PPOksPaa!|_pez
`golgLvlolq2L
`oz”agz
`
`
`
`
`
`
`
`
`Y¥NVEONITHEYNVEONIAVKopAYMALY9)KopJOIARGFOTOONIAVdONITIA
`_SLvadnAD\9¢¢PUNdivddnAdyGNY¥\ONYNOLWOISILON=dE?\LInsad
`NOWVSISHONO8¢
`veeNOILOVSNVE!aetnaoz
`
`
`
`?NOWWASOSN) |j———Cee
`gee"
`
`
`INFWAYdNOLLOVSNVELLLNJIAAYd
`
`r*~~_ee
`NOLLOANNOS78L¢NadoNOLLVINYOSNI«OLAVd:GNISrzpo
`
`
`
`NISO1G22ecoz|__NDT
`l.cpatle
`[~
`
`
`
`NOMLOSNNOOU3ad-Ol-WaadHSNSVISI80z
`LooLa)
`
`7qi0130IsvaavOuS|
`
`
`
`
` (ISDILdaOV
`
`giz
`NOLLOSNNOONadO
`
`
`STIIdSAILOVGNSSOLZ
`
`
`
`
`
`THELddDOV
`
`3Svd1sd
`
`aaa2D°3oO
`
`LLa>Oo
`
`i®2>Oo
`
`S©°°o
`SoN—°xR®D©oO—ai°Oo
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 7 of 20
`
`
`
`

`

`Patent Application Publication
`
`Mar. 17, 2011 Sheet 7 of 10
`
`US 2011/0066550 Al
`
`88
`
`
`
`
`
`JUaSAlq
`
`
`
`
`
`ODIAIaSUNMET
`
`06
`
`25)
`
`
`
`00'°S8$JUNOWY
`
`:#éUONEZHOUINY
`
`“Agpled
`
`sayeqAed
`
`88
`
`
`
`SOL$XPL
`
`
`
`S6ClSSELB)
`
`BdIAIaSUME
`
`ra
`
`JeleivTe
`
`Bulllig
`
`UNOWY
`
`“S}B}8Q
`
`
`
`
`
`dmesMOSIHIGBAB|BUGeeLAAl
`
`
`
`
`
`Buy9eygG@ASVHOuwnasay
`IY00:6JeLiv[ie
`
`
`
`
`
`
`
`dnyasAoysth}=figeBA@d|Suliiig3AI?
`
`
`00°S9$ O0°0Z$BsiG2'e
`
`JUBSIId
`
`OFDla
`
`
`
`aaa2D°3oO
`
`Oo
`
`LLaSs
`
`i®2>Oo
`
`S©°°o
`SoN—°©®D©oO—ai°Oo
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 8 of 20
`
`
`
`
`

`

`Patent Application Publication
`
`Mar. 17, 2011 Sheet 8 of 10
`
`US 2011/0066550 Al
`
`judsald
`
`v6WYMOWOWOL=ejeqAe
`
`
`
`
`
`
`
`dnasAOS]=igBAe|Buljig
`eeAela
`
`
`
`Gupjayg@aAsvHoqunoooy
`sloquBlen QSVelLepS+UONPZHOUNYpary=--Agpled
`
`
`WY00:6deLely[jee
`BdIAIaSUME]104
`
`an'se$UNOWY
` 0620iAl@SUne|SOF|S1a]]14
`
`
`
`
`
`
`
`
`AOSIH|ilgeAeg) SuliiidS|)J
`
`NV00:6deLeiy[pee
`
`
`adIAlagBuiysAgegsans
`
`eel
`
`aaa2D°3oO
`
`Oo
`
`LLaSs
`
`i®2>Oo
`
`S©°°o
`SoN—°o>)®D©oO—ai°Oo
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 9 of 20
`
`
`
`
`

`

`Patent Application Publication
`
`Mar. 17, 2011 Sheet 9 of 10
`
`US 2011/0066550 Al
`
`OO!
`
`
`Buryjoay9
`
`
`
`
`
`uMe"]S,80Po00'ss$LO/vOO)
`
`
`
`
`
`dnyasigeAedGung
`00'S9$ODe$BSsGee
`GOclS—SHELBY)
`GOL$xeL
`LOLYSsor0}pled
`
`NOTAWANeunoo9
`WY00:6DeLelyfio
`Tea20Gel“#uoloesuely
`aeyunoooy
`
`QSIAI9SUME]SaIqLL
`
`00'S8$[BOL
`asjsa[|
`(Ala
`
`
`
`
`
`
`OO'GE$
`
`
`AOISIH|fgeAeg=Bulg
`
`
`UME]S,80PCO'S8$86
`HONDA22S00'S?I$
`umolgX8l¥
`WY00:6deperv[poe
`
`AemayesLLlegs
`
`
`
`
`
`
`
`‘seed
`
`
`
`
`
`
`
`ee
`
`dnyas
`
`
`
`FSDit
`
`aaa2D°3oO
`
`LLa>Oo
`
`i®2>Oo
`
`S©°°o
`SoN—3Oo=®D©oO~ai3Oo
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 10 of 20
`
`
`
`

`

`Patent Application Publication
`
`Mar. 17, 2011 Sheet 10 of 10
`
`US 2011/0066550 Al
`
`
`
`
`
`
`
`
`
`
`
`Z£Dll9DIA
`
`dmjesAlosiHgekegGung
`WY00-69¢Lely[iINV00:6pepeivyge
`SAPe
`
`v0l;peq=00'001$
`
`
`
`
`spun4|dmesgjigeAegOuniia—alL\@G'SDB ArcisiH
`
`
`
`
`
`
`
`BupjpsygGP3SvHo“junasay
`
`Wi
`
`
`
`JaJsuel|spun4
`
`ect
`
`cOl
`
`
`
`“OQWNNsuoud
`
`Junowy
`
`aaa2D°3oO
`
`LLaSOo
`
`i®2>Oo
`
`S©°°o
`SoN—3<=®D©oO~ai3Oo
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 11 of 20
`
`
`
`
`

`

`US 2011/0066550 Al
`
`Mar. 17, 2011
`
`SYSTEM AND METHOD FOR A SECURE
`FUNDS TRANSFER
`
`TECTINICAL PIELD
`
`[0001] This disclosure relates generally to funds transfers,
`and more particularly to a system and method for a secure
`fundstransfer.
`
`BACKGROUND
`
`[0002] A payer may transfer fundsto a biller using a tradi-
`tional payment instrument, such as cash, a check, or a credit
`card. [hese payment instruments, however, may be vulner-
`able to loss or theft. Additionally, an unauthorized user may
`easily obtain the account numbers of checks and credit cards
`and may use the account numbersto access the funds.
`[0003] Mobile phone payment systems mayuse bank web
`pages or text messages, and mayprovide an alternative to
`traditional payment instruments. These systems, however,
`may fail to adequately secure funds transfers. Accordingly,
`these systems may limit the functionality available to a user
`and/or the dollar amount that may be transferred in order to
`minimize the attects of fraud.
`
`SUMMARY
`
`more other technical advantages may be readily apparent to
`one skilled in the art from thefigures, descriptions, and claims
`included herein.
`
`
`
`BRIEF DESCRIPTION OF THE DRAWINGS
`
`[0007] Amore complete understanding of embodiments of
`the disclosure will be apparent fromthe detailed description
`taken in conjunction with the accompanying drawings in
`which:
`FIG.1 illustrates an example of a network fortrans-
`[0008]
`acling a secure fundstransfer;
`[0009]
`FIG.2 illustrates an example of a node for transact-
`ing a secure fundstransfer;
`[0010]
`FIGS. 3A-3Gillustrate an example method forset-
`ting up a device to securely transfer funds using the gateway
`of FIG. 1;
`[0011]
`FIGS. 4A-4F illustrate an example methodfor trans-
`acting a secure fundstransfer,
`[0012]
`FIGS. 5A-5Billustrate an example of an archive for
`tracking completed secure fundstransfers;
`[0013]
`FIG.6 illustrates an example of a secure fundstrans-
`fer that may be completed by the paying device alone; and
`[0014]
`FIG.7 illustrates an example of an ATM interface
`for transacting, a secure fundstransfer.
`
`
`
`DETAILED DESCRIPTION
`
`invention and its
`[0015] Embodiments of the present
`[0004] According to one embodiment, a gatewayreceives a
`advantages are best understood by referring to FIGS. 1
`transaction from a first device in local communication with a
`through 7 ofthe drawings, like numerals being used forlike
`second device. ‘The transaction includes a payment amount
`and corresponding parts ofthe various drawings.
`and a plurality of authorization codes. ‘he gateway uses the
`[0016]
`In some embodiments, a payment maybe trans-
`authorization codes to authorize the transaction and to deter-
`ferred between devices, such as mobile phones, using a secure
`mine an account for each device. The gatewaythen instructs
`fundstransfer. The secure funds transfer may ensure that each
`device is authorized to access the bank accounts selected for
`an account manager to withdrawthe payment amount from
`the accountofthefirst device and to deposit it into the account
`making and receiving the payment. The secure funds transfer
`of the second device. A result is received at the gateway, and
`maybe transacted byindividuals, small businesses, such as
`the gatewaysends the result to each device.
`lawn businesses or babysitters, merchants, such as grocers,
`[0005] Certain embodimentsof the invention may provide
`gas stations, or dry cleaners, and/or other suitable parties. The
`one or more technical advantages. A technical advantage of
`funds maybetransferred for any suitable purpose, including
`one embodiment maybe that the security of fundstransfers
`paying rent, purchasing dinner, or receiving an income tax
`may be increased and vulnerabilities to fraud may be
`loan. In some embodiments, the secure funds transfer may
`decreased. As an example, payees may be created dynami-
`reducethe costs, [fraud risks, and time requirements of funds
`cally and discarded after a single transaction, and payments
`transfers. For example, funds may be transferred approxi-
`may be made without transmitting certain confidential infor-
`mately in real-tume suchthat a bank receives instructions to
`mation, such as account numbers. As another example, funds
`performa fundstransfer within approximately a few minutes
`transfers may require paying and billing devices to be in close
`ofa user requesting the fundstransfer. In some embodiments,
`proximity. In some embodiments, the proximity requirement
`funds maybetransferred betweenusers whoare not already
`may be enforced by comparingthe location coordinatesofthe
`signed up with the same bank orcredit card company, thercby
`devices. Another technical advantage maybe that transaction
`allowing for convenient access to funds.
`times may be improved over paper checks byinstructing a
`[0017] TIG.1illustrates an example of a network 10 for
`bank to transfer funds at approximately the time the device
`transacting a secure funds transfer. In some embodiments,
`requests the funds transfer. Additionally, an account balance
`network 10 may comprise a plurality of nodes.A node may
`maybe verified at approximatelythe time the device requests
`comprise an interface, logic, and memory, such as the node 20
`the funds transfer to ensure that a paying account contains
`described in FIG. 2 below. Examples of the nodes of the
`sufficient funds to complete the transaction. As yet another
`network 10 mayinclude one or more devices 12, a gateway
`example, the secure fundstransfer may transact payments and
`14, and one or more account managers 16. In some embodi-
`record the payments electronically, and may therefore reduce
`ments,the gateway 14 may authorize a device 12 to initiate a
`the paper usage required by paper checks and paper records
`function. For example, the gateway 14 mayreceive a number
`systems. Decreasing fraud, ensuring the availability of funds,
`of authorization factors describing the device 12, authorize
`and reducing paper usage mayallow fortransactionscosts to
`the device 12 according to the authorization factors, and
`be reduced.
`instruct the account manager16 to performthe functionifthe
`authorization is successful. In some embodiments, the func-
`tion may comprise a funds transfer and the authorization
`
`[0006] Certain embodiments of the invention may include
`none, some, or all of the above technical advantages. One or
`
`
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 12 of 20
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 12 of 20
`
`

`

`US 2011/0066550 Al
`
`Mar. 17, 2011
`
`factors may include a transaction indicating a payment
`amount anda plurality of authorization codes for authorizing
`one or more devices 12.
`[0018] The device 12 may comprise any device requiring
`authorization to initiate a function. In some embodiments, the
`device 12 may be a mobile device, such as a mobile phone, a
`Personal Digital Assistant (PDA), or a laptop computer. In
`some embodiments, the device 12 may be configuredto deter-
`mine its current location. For example, the device 12 may
`include a Global Positioning System (GPS)receiver operable
`to determineits latitude and longitude coordinates according
`to a signal received from a GPS transmitter, such as a satellite
`system,or other device suitableto establish geographic loca-
`tion.
`
`In some embodiments, the device 12 may be con-
`[0019]
`figured to communicate locally with another device 12. Local
`communication maybe characterized by comnmunicationthat
`may not extend beyond a specified radius, such as less than
`100 feet or, for example, less than 25 feet.'The local commu-
`nication may be througha physical connection, such as a wire
`or cable, or a wireless connection, such as a short-range
`wireless communication protocol. Examples of short-range
`wireless communication protocols include BIUETOOTH
`and Near Field Communication (NFC). In some embodi-
`ments, short-range wireless transmissions may comprise
`radio transmissions,
`infrared transmissions, or any other
`short-range transmissions. In some embodiments, the short-
`range wireless communication protocol may be configured
`for a highlevel of security.
`[0020]
`In some embodiments, the network 10 may include
`a paying device 12a and a billing device 125. The billing
`device 125 may be a mobile device as described above or a
`stationary device, such as an Aulomatic Teller Machine
`(ATM)or a payment terminal at a store. The paying device
`12a and the billing device 126 mayestablish a local commu-
`nication session to generate a transaction.lhe devices 12 may
`exchangetermsofthe transaction, such as a payment amount,
`the account from which funds will be withdrawn, and the
`account to which the funds will be deposited. Upon a deter-
`mination that the transaction terms are complete, the paying
`device 12a may sendthe transaction to the gateway 14.
`[0021]
`In some embodiments, the pateway 14 maybe a
`node, such as a computer, or a number of nodes, such as a
`network, for controlling access to other nodes of the network
`10. forexample, the gateway 14 maycontrol access by autho-
`rizing the device 12 to initiate a requested function. In some
`embodiments, the authorization may be determined accord-
`ing to a plurality of authorization factors. If the authorization
`succeeds, the gateway 14 mayinstruct other nodesofnetwork
`10 to performthe function requested by the device 12. If the
`authorization fails, the gateway 14 maynotinitiate the func-
`tion requested by the device 12.
`the authorization factors
`[0022]
`In some embodiments,
`may include the GPS coordinates of the device(s) 12 being
`authorized. The GPS coordinates of cach device 12 may be
`compared to the GPS coordinates of the device’s expected
`location to verify that the coordinates substantially match. As
`an example, the expected location of a device 12 may be a
`homeaddress or a business address indicated by a userprofile
`associated with the device 12. As another example,
`the
`expected location ofthe paying device 12¢@ maybe proximate
`to the current location ofthe billing device 12. The coordi-
`nates may substantially match if they are within close prox-
`imity to one another, suchas less than 100 feetor, for example
`
`less than 2 feet. A known margin of error of the location
`technology may be considered in determining whether the
`coordinates substantially match.
`[0023]
`Insome embodiments, the gateway 14 mayinstruct
`an account manager 16 to perform an authorized function. In
`some embodiments, the account manager 16 may be a com-
`puter or a computer network configured to perform a func-
`tion, for example,
`to manage the funds of an account.
`
`Examples of accounts may include savings accounts, check-
`ing accounts, credit card accounts, debit card accounts, stored
`value cards, lines ofcredit, mobile credit accounts, and/or any
`othersuitable account. Accounts may be located anywhere in
`the world and are independentofthe locationof the device.
`‘The account manager 16 may be administered by anentity,
`such as a bank or a credit card company associated with the
`account.
`
`Insome embodiments, the gateway 14 mayreceive
`[0024]
`a transaction from the paying device 124 requesting to trans-
`fer funds from a payer’s account managed by a payer’s
`account manager 16a. ‘The device 12a may request that the
`fundsbetransferred to a biller’s account managed by a biller’s
`account manager 164. The account managers 16 may or may
`not be administered by the same entity depending on whether
`the payer andthe biller hold accounts with the same entity
`(e.g., the same bank). The gateway 14 mayauthorize the
`transaction and mayinstructthe payer’s account manager16a
`to transfer the funds. The payer’s account manager 16a may
`transfer the funds using any suitable method, such as an
`
`Electronic Funds Transfer (EFT), for example, an Automated
`Clearing House (ACH) transfer, or a check. The payer’s
`account manager 16a maytransfer funds directly to the bill-
`er’s account manager 164, or may transfer the funds via an
`intermediary such as the gateway 14. The payer’s account
`manager 16a maythen return a result to the gatewayindicat-
`ing whether the transfer was successful or unsuccessful.
`Example causes of an unsuccessful result may include insuf-
`
`ficient fundsin the payer’s account, failure to receive a correct
`bank password, or network error.
`[0025] The nodes of network 10 may communicate using
`anysuitable network configuration. Examples mayinclude,
`butare notlimited to, a public or private data network; a local
`area network (LAN); a metropolitan area network (MAN); a
`wide area network (WAN); a wireline or wireless network; a
`local, regional, or global communication network; an optical
`network; a satellite network; an enterprise intranet; other
`suitable communication links; or any combination of the
`preceding. In some embodiments, the gateway 14 may com-
`municate with a device 12 using a browser-based mobile web
`service, and the gateway 14 may communicate with an
`account manager 16 using the internet.
`[0026] Modifications, additions, or omissions may be made
`to systemsdescribed herein without departing from the scope
`of the invention. The components of the systems may be
`integrated or separated. Moreover, the operations ofthe sys-
`tems maybe performed by more, fewer, or other components.
`For example, in some embodiments,certain messages may be
`communicated directly between the gateway 14 andthebill-
`ing device 124 and/or the gateway14 andthe biller’s account
`manager 164. Operations of the systems may be performed
`using any suitable logic comprising software, hardware, and/
`or other logic. As used in this document,“each”refers to each
`memberof a set or each memberof a subsetofa set.
`
`FIG. 2 illustrates an example of a node 20 fortrans-
`[0027]
`acting a secure funds transfer. In certain embodiments, the
`
`
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 13 of 20
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 13 of 20
`
`

`

`US 2011/0066550 Al
`
`Mar. 17, 2011
`
`Go
`
`node 20 may comprise a device, a gateway, or an account
`manager,such as the device 12, the gateway14,or the account
`manager16 of FIG.1.
`[0028]
`In certain embodiments, node 20 may include an
`interface 30, logic 32, memory 34, and/or other suitable ele-
`ments. Interface 30 receives input, sends output, processes the
`input and/or output, and/or performs other suitable opera-
`tions. In certain embodiments, an interface 30 of gateway 14
`receives one or more authorization factors for authorizing a
`function and outputs an instruction to perform the authorized
`function. Interface 30 may comprise hardware and/or sofi-
`ware.
`
`[0029] Logic 32 performsthe operations ofthe component,
`for example, executes instructions to generate output from
`input. In certain embodiments, logic 32 of gateway 14 may
`authorize a function, such as a fundstransfer, according to the
`authorization factors, such as a plurality of authorization
`codes(e.g., security keys). In some embodiments, the autho-
`rization codes may be configured to represent confidential
`information. Examples of confidential
`information may
`include a user name or an account numberfor a bank account.
`As an example, a transaction may be requested for an account
`number“12345678.” Logic 32 may generate an authorization
`code, such as “22B7465Z,” to represent the account number.
`Authorization codes may include any suitable number of
`bytes and any suitable characters. In some embodiments, the
`authorization code maybevalid for a single transaction. The
`authorization code maybe deleted aller the single transaction
`and an updated authorization code may be generated for a
`next transaction. In some embodiments, the authorization
`codes may be encrypted prior to transmission froma first
`node 20 and decrypted uponreceipt at a second node 20. In
`some embodiments, separate account authorization codes
`may be generated for each account of a particular device.
`[0030] Logic 32 mayinclude hardware (such as a processor
`40), software (such as applications 44), and/or other logic.
`Logic 32 may be encoded in one or more tangible media and
`may perform operations when executed by a computer. Cer-
`tain logic 32, such as a processor 40, may manage the opera-
`tion of a component. Examplesof a processor 40 include one
`or more computers, one or more microprocessors, one or
`more applications, and/orotherlogic.
`[0031]
`In particular embodiments, the operations of the
`embodiments may be performed by one or more computer
`readable media encoded with a computer program, software,
`computer executable instructions, and/or instructions capable
`of being executed by a computer.In particular embodiments,
`the operations of the embodiments may be performed by one
`or more computer readable media storing, embodied with,
`and/or encoded with a computer program and/or having a
`stored and/or an encoded computer program.
`[0032] Memory 34 stores information. Memory 34 may
`comprise one or more tangible, computer-readable, and/or
`computer-executable storage medium, and mayexclude sig-
`nals or carrier waves. Examples ofmemoryinclude computer
`memory (for example, Random Access Memory (RAM) or
`Read Only Memory (ROM)), mass storage media (for
`example, a hard disk), removable storage media (for example,
`a Compact Disk (CD) or a Digital Video Disk (DVD)), data-
`base and/or network storage (for example, a server). and/or
`other computer-readable medium.
`[0033] Modifications, additions, or omissions may be made
`to node 20 without departing fromthe scopeofthe invention.
`The components of node 20 maybe integrated or separated.
`
`Moreover, the operations of node 20 may be performed by
`more, fewer, or other components. Additionally, operations of
`node 20 may be performed using any suitable logic compris-
`ing software, hardware, and/orotherlogic.
`[0034]
`FIGS. 3A-3Gillustrate an example method forset-
`ting up a device 12 to securely transfer funds using the gate-
`way 14 of FIG. 1. Setting up the device 12 may include
`registering and activating a user profile. The registration and
`activation may utilize one or more security checks. Accord-
`ingly, in some embodiments, setting up the device 12 may be
`required prior to conducting the first funds transfer.
`[0035]
`In some embodiments, the method begins with a
`user downloading a funds transfer application to the device.
`The application may be downloaded from any suitable
`source, such as a bank’s website, an email attachment, or an
`application store of a software provider. The application store
`mayincludea list of available applications sorted according
`to newness, popularity, interest (e.g., finance), or any other
`suitable category. FIG. 3A illustrates an example of a finance
`category50 that includes a Peer-to-Peer (P2P) Payment appli-
`cation 52. The user may select the P2P Payment application
`52 for more information. FIG.3B illustrates sample informa-
`tion for the application including a software provider’s name
`54, a rating 56, a link to customer reviews 58, a download
`price button 60, and a description of the application 62. The
`description 62 may indicate the application’s purpose, the
`device requirements for the particular embodiment of the
`application, and a list of participating entities. The user may
`review the information and mayselect to downloadthe appli-
`cation, for example, by pressing the download price button
`60.
`
`[0036] After downloading the application, the user may
`create a userprofile. FIG. 3C illustrates an example of a user
`profile 66. In some embodiments, the user profile may be
`accessed from a user configuration menu 64, and it may
`include a user name, a street address (e.g., a home address or
`a business address), an email address, and/or an application
`password. The application password. may be a password for
`accessing the application, and it may be configured to be
`verified by any suitable node, such as the device 12 itself or
`the gateway 14. Verifying the application password at the
`gateway 14 may reduce the likelihood of the application
`being accessed if the device 12 becomeslost orstolen.
`[0037]
`In some embodiments, the user may press a regis-
`tration button 64 to instruct the device 12 to send the com-
`pleted user profile 66 to the gateway14. The gateway 14 may
`register the userprofile 66 and maystore the registered profile
`in a database that may be accessed during subsequent funds
`transfers. Accordingly, the user need not re-enter the infor-
`mation for each funds transfer.
`
`[0038] The method may require activating the userprofile
`66 prior to the first transaction. In some embodiments, the
`gateway 14 maysend an activation key to the user for acti-
`vating the registered user profile 66. For example, the activa-
`tion key maybe sent to the email address indicated by the user
`profile. The activation key may include one or more security
`features. As an example, the activation key may expire after a
`relatively short period of time.
`[0039]
`To activate the user profile 66, the user may create an
`activation requestincluding the application password andthe
`activation key 70, as shown in FIG. 3D. The user mayinstruct
`the device 12 to send the activation request to the gateway by
`pressing an activation button 72. In some embodiments, the
`device 12 may include the GPS coordinates of its current
`
`
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 14 of 20
`
`GOOG-1011
`Google LLC v. RFCyber Corp. / Page 14 of 20
`
`

`

`US 2011/0066550 Al
`
`Mar. 17, 2011
`
`location in the activation request. The gateway 14 mayautho-
`rize the device 12 by verifying the application password, the
`activation key 70, and/or the GPS coordinates. In some
`embodiments, the GPS coordinates may be compared to the
`street address indicated by theuserprofile 66. The registration
`may be activated ifthe GPS coordinates substantially match
`the street address, for example, if the GPS coordinates are
`within 100 feet of the street address. The gateway 14 may be
`configured to consider a marginoferror of the location tech-
`nology when determining if the coordinates substantially
`match.
`
`the user may access an
`In some embodiments,
`[0040]
`accounts configuration menu to setup one or more accounts
`for making and/or receiving payments, performing balance
`inquiries, or any other suitable function. FIG. 3E illustrates an
`example accounts configuration menu 74 wherein the user
`may first select an account
`type 76 to be configured.
`Fxamples of account types mayinclude savings accounts,
`checking accounts, credit card accounts, debit card accounts,
`stored value cards, lines of credit, mobile credit accounts,
`and/or any other suitable account.
`[0041]
`FIG. 3F illustrates an example for configuring a new
`checking account, however, any type of account may be con-
`figured. The user may enter account information, such as a
`bank identifier and a checking account number. For credit
`card, debit card, stored value card, and/or gift card configu-
`rations (not shown), account information may include a card
`number, an expiration date, and a card security code, such as
`a Card Verification Value (CVC) 2 code. In addition to the
`type-specific account information, each account maybe con-
`figured with an account password. During a transaction, the
`account password maybeverified by any suitable node, such
`as the device 12 itselfor the gateway 14. Verifying the account
`password at the gateway 14 may reducethe likelihood of the
`account being accessed if the device 12 becomes lost or
`stolen. In some embodiments, the account configuration may
`include information to be passed throughthe gateway 14 to an
`account manager, such as a login name and a bank password
`for accessing a website of the user’s bank.
`[0042]
`In some embodiments, the user may configure the
`application to access multiple accounts. A default configura-
`tion menu 78 may beused to select preferred accounts for
`certain transactions. FIG. 3G illustrates an example of default
`settings. The user mayselect the default account(s) for mak-
`ing payments 80 as well as the default account(s) for receiv-
`ing payments 82. In some embodiments, the user mayselect
`more than one default account for making or receiving pay-
`ments. For example, the user may select to pay personal
`expenses from a checking account and to pay business
`expenses from a credit card account.
`[0043]
`In some embodiments,
`setting up the device
`includes receiving one or more authorization codesfor autho-
`rizing the first transactionof the device 12. Upon completing
`the setup method, the device 12 maybe usedto transfer funds.
`[0044] Modifications, additions, or omissions may be made
`to the previously described method without departing from
`the scope of the disclosure. The method may include more,
`fewer, or other steps. For example, in some embodiments the
`P2P Payment application 52 may be downloaded directly
`from a bank’s website. The bank’s website may transfer an
`existing user profile 66 and account informationto the gate-
`way14 without requiring the user to separately configure,
`register, and/or activate the application. Alternatively, the
`registration and/or activation may be doneoffline through a
`
`call center of the bankora file fe