NetCheque and NetCash are service marks of the
`University of Southern California. All other
`product or service names are trademarks or
`service marks of their respective owners.
`
`Usenix® Tutorial on Electronic Commerce
`
`Getting Paid on the Internet
`
`B. cnrford Neuman
`
`University of Southern California
`
`Information Sciences Institute
`
`Copyright © 1995 University of Southern California
`
`1
`
`PayPal Ex.1016, p.1
`
`
`University of Southern California. All other
`product or service names are trademarks or
`service marks of their respective owners.
`
`Usenix® Tutorial on Electronic Commerce
`
`Getting Paid on the Internet
`
`B. cnrford Neuman
`
`University of Southern California
`
`Information Sciences Institute
`
`Copyright © 1995 University of Southern California
`
`1
`
`PayPal Ex.1016, p.1
`
`
`
`tives and Syllabus
`
`»:» Discuss requirements for network payment
`
`ozo Understand kinds of payment methods
`
`6
`
`»:» Learn what systems are available
`5.« Discuss integration with applications
`~:« Consider risks and discuss security
`
`~:»Discuss role and rewards for providers
`
`Copyright © 1995 University of Southern California
`
`2
`
`PayPal Ex.1016, p.2
`
`
`
`ionalcourserelatedmaterial
`
`Additional material about many systems
`covered in class can be found on the web.
`
`This material includes:
`
`— Marketing material for particular systems
`
`~— Technical papers describing some of the systems
`
`- Mailing lists and discussion groups
`
`Links to this material have been collected as:
`
`http: / /nii.isi.edu/ courses /net___payment.html
`
`Copyright © 1995 University of Southern California
`
`3
`
`PayPal Ex.1016, p.3
`
`
`
`US
`
`(C Discuss requirements for network payment
`Understand kinds of payment methods
`
`Learn what systems are available
`Discuss integration with applications
`
`Consider risks and discuss security
`
`Discuss role and rewards for providers
`
`Copyright © 1995 University of Southern California
`
`4
`
`PayPal Ex.1016, p.4
`
`
`
`
`
`»:« Many services envisioned for the Internet
`will only be realized if service providers are
`compensated for the services they provide:
`— Access to copyrighted materials
`
`—— Database searches
`
`—— Consumption of system resources
`—— Merchandise delivered outside the system
`
`- Services provided outside the system
`
`Copyright © 1995 University of Southern California
`
`.
`
`5
`
`PayPal Ex.1016, p.5
`
`
`
`
`
`irements for payment services
`
`Secure, reliable, flexible, scalable,
`efficient, and unobtrusive payment
`methods are required asa basic
`service of the Internet and must be
`integrated with existing and
`evolving applications.
`
`Copyright © 1995 University of Southern California
`
`6
`
`PayPal Ex.1016, p.6
`
`
`
`
`
` tr irements: Security
`
`«to Information services are provided
`today on relatively open networks.
`
`»:~ Payments involve actual money; such
`systems will be a target for criminals.
`
`oz» The infrastructure supporting electronic
`commerce must be usable on open
`networks and resistant to attack.
`
`Copyright © 1995 University of Southern California
`
`7
`
`PayPal Ex.1016, p.7
`
`
`
`
`
` or irements: Reliability
`
`o:o Commerce will depend on the availability
`of the billing infrastructure.
`
`»:~ The infrastructure may be a target of
`attack for Vandals.
`
`The infrastructure must be highly
`available and should not present a single
`point of failure.
`
`Copyright © 1995 University of Southern California
`
`8
`
`PayPal Ex.1016, p.8
`
`
`
`
`
`iremem‘s: Flexibility
`
`«:« Different models for different situations:
`
`—— credit card, cash, check
`
`»:« Different assurances are provided:
`—~ accountability, anonymity, risk
`
`oz» There is a need for a common framework.
`
`oz» Convertibility is needed across models
`
`Copyright © 1995 University of Southern California
`
`9
`
`PayPal Ex.1016, p.9
`
`
`
`
`
`; irements: Scalability
`
`«:~ The payment infrastructure should
`support multiple independent
`accounting servers and should avoid
`central bottlenecks.
`
`«to Users of different accounting servers
`must be able to transact business with
`
`one another and the funds must be
`
`automatically cleared between servers.
`
`Copyright © 1995 University of Southern California
`
`10
`
`PayPal Ex.1016, p.10
`
`
`
`
`
`irements: Efficiency
`
`+:« Frequent payments for small amounts
`must be supported (micropayments).
`«to Performance must be acceptable, even
`when multiple payments are required.
`oz» Merchants and payment servers must
`be able to handle the load.
`
`«to Per-transaction cost must be small
`enough that it is insignificant.
`Copyright © 1995 University of Southern California
`V
`
`11
`
`PayPal Ex.1016, p.11
`
`
`
`
`
`irements: Unobtrusive
`
`~:« Users should not be constantly
`interrupted to provide payment
`information.
`«z» However, users do want to control
`when, to whom, and how much is paid.
`oz» Users must be able to monitor their
`
`spending.
`
`
`
`Copyright © 1995 University of Southern California
`
`12
`
`PayPal Ex.1016, p.12
`
`
`
` ¢>;» irements: Integration
`
`oz» Payment systems must be tied to the
`existing financial infrastructure.
`
`oz» Applications must be modified to use the
`the payment infrastructure.
`oz» Payments should be supported by common
`protocols that underlie applications.
`
`oz» A common framework should support
`integration of multiple payment methods.
`
`Copyright © 1995 University of Southern California
`
`13
`
`PayPal Ex.1016, p.13
`
`
`
`Discuss requirements for network payment
`
`«c Understand kinds of payment methods
`
`Learn What systems are available
`
`Discuss integration with applications
`
`Consider risks and discuss security
`
`Discuss role and rewards for providers
`
`Copyright © 1995 University of Southern California
`
`14
`
`PayPal Ex.1016, p.14
`
`
`
`
`
`»:» Secure presentation
`
`«z» Electronic currency
`
`
`
`oz» Credit- debit instruments
`
`Copyright © 1995 University of Southern California
`
`4
`
`15
`
`PayPal Ex.1016, p.15
`
`
`
`(2 forms of payment
`
`Secure presentation
`
`oz» Uses traditional credit card numbers
`
`oz» As safe as the phone
`
`oz» No customer signature (presently)
`
`«:~ Potentially huge customer base
`
`«:» Little need for infrastructure
`
`Copyright © 1995 University of Southern California
`
`-
`
`16
`
`PayPal Ex.1016, p.16
`
`
`
`ples of secure presentation
`
`~:« NetScape’s commerce server
`
`oz» Secure Mosaic
`
`oz» CyberCash’s initial offering
`
`oz» iKP [1 and 2]
`
`Copyright © 1995 University of Southern California
`
`17
`
`PayPal Ex.1016, p.17
`
`
`
`
`
`iderations: secure presentation
`
`oz» Integrity and confidentiality
`
`»:» Who sees the account number
`
`«:« Is the payment order signed
`
`oz» Is the merchant 1egitimate
`
`«:« Real time authorization
`
`«z» Transaction cost
`
`Copyright © 1995 University of Southern California
`
`1g
`
`PayPal Ex.1016, p.18
`
`
`
`e forms of payment
`
`Electronic currency
`
`oz» Potential for anonymity
`
`«to Potential for off—1ine operation (debated)
`
`oz» Requires extensive matching capabilities
`
`Copyright © 1995 University of Southern California
`
`V
`
`' 19
`
`PayPal Ex.1016, p.19
`
`
`
`ples of electronic currency
`
`~:« Chaum’s DigiCash
`
`oz» Mondex
`
`oz» USC/ISI’s NetCash5M
`
`Copyright © 1995 University of Southern California
`
`I
`
`20
`
`PayPal Ex.1016, p.20
`
`
`
`
`
`iderations: electronic currency
`
`oz» Integrity and security
`
`+:« On-line VS. off—1ine
`
`»:« Is tamper resistant hardware needed
`
`oz» Who is at fault for counterfeit currency
`
`ozo Kinds of anonymity
`
`(continued)
`
`Copyright © 1995 University of Southern California
`
`21
`
`PayPal Ex.1016, p.21
`
`
`
`
`
`iderations: electronic currency
`
`(continue(1)
`»:+ Transaction cost
`
`«:« Storage requirements
`
`«to Getting money in and out of the system
`
`«to Backing of the currency
`
`Copyright © 1995 University of Southern California
`
`22
`
`PayPal Ex.1016, p.22
`
`
`
`e forms of payment
`
`Credit—debit instruments
`
`oz» Only authorized individuals can spend
`from particular accounts
`
`»:« Records of transactions maintained
`
`a
`
`«to Requires new infrastructure
`
`Copyright © 1995 University of Southern California
`
`’
`
`i
`
`23
`
`PayPal Ex.1016, p.23
`
`
`
`ples of credit—debit model
`
`~:« First Virtual
`
`t
`
`«z» USC /ISI’s NetCheque5M
`
`~:» CMU’s NetBi11
`
`oz» FSTC’s Electronic Check project
`
`Copyright © 1995 University of Southern California
`
`24
`
`PayPal Ex.1016, p.24
`
`
`
`
`
`~
`
`iderationsz credit-debit
`
`«:- Security for the instrument
`
`»:+ Compromise of user's keys
`«:« Who incurs risk
`i
`
`—— From compromised account
`
`- From unpaid bills
`
`+:+ Real time authorization
`
`oz» Transaction cost
`
`Copyright © 1995 University of Southern California
`
`V
`
`25
`
`PayPal Ex.1016, p.25
`
`
`
`forms ofpayment
`
`Direct Transfer
`oz» Customer initiates transfer of funds to
`account of the merchant
`
`Collection agent
`oz» Payment collected by third party who
`informs merchant that payment has
`been made.
`
`Copyright © 1995 University of Southern California
`
`25
`
`PayPal Ex.1016, p.26
`
`
`
`/us
`\/
`Discuss requirements for network payment
`
`Understand kinds of payment methods
`
`<- Learn what systems are available
`
`Discuss integration with applications
`
`Consider risks and discuss security
`
`Discuss role and rewards for providers
`
`Copyright © 1995 University of Southern California
`
`27
`
`PayPal Ex.1016, p.27
`
`
`
`7713 to be diSCuSSed {notacomplete list ofsystems)
`
`oz» Fist Virtual
`
`oz» NetScape
`oz» Secure Mosaic
`
`oz» CyberCash
`
`oz» iKP
`
`oz» NetCheque
`
`vzo NetBi11
`oz» FSTC’s Electronic Check
`
`ozo DigiCash
`
`oz» NetCash
`
`oz» Open Market (integration) oz» Mondex
`
`Copyright © 1995 University of Southern California
`
`28
`
`PayPal Ex.1016, p.28
`
`
`
`Virtual
`
`«to Customer establishes First Virtual account
`
`oz» Customer sends account ID tomerchant
`
`«z» Merchant forwards to FV server
`
`oz» FV server verifies through e-mail to customer
`
`—— Customer can refuse payment to merchant
`— If too frequent, customer loses account
`
`
`
`
`
`oz» Does not use encryption
`
`Copyright © 1995 University of Southern California
`
`29
`
`PayPal Ex.1016, p.29
`
`
`
` ‘ Virtual (continued)
`
`o: No changes to client software
`
`oz» Minimal changes needed for merchant
`
`oz» Exposure limited by delaying payment to
`merchant (waived for vetted merchants)
`
`oz» Available today
`
`Copyright © 1995 University of Southern California
`
`30
`
`PayPal Ex.1016, p.30
`
`
`
` cape and SecureMosaic
`
`oz» Example of secure presentation
`
`+:» Merchant has certified public key
`
`«to Client submits form with credit card
`information to merchant encrypted
`
`oz» Merchant obtains authorization for credit
`
`card in same Inanner as for phone order
`
`«:~ Available today
`
`Copyright © 1995 University of Southern California
`
`31
`
`PayPal Ex.1016, p.31
`
`
`
`rCash
`
`«z» Example of secure presentation
`
`«to CyberCash software running on client
`encrypts credit card number and transaction
`amount using CyberCash public key and
`sends to merchant
`r
`
`
`«to Merchant forwards to CyberCash server
`which obtains credit card authorization and
`
`responds to merchant
`
`Copyright © 1995 University of Southern California
`
`32
`
`PayPal Ex.1016, p.32
`
`
`
`rCash (continued)
`
`~:~ Credit card number not exposed to merchant
`
`-to Payment clears through credit Card system
`
`«:o Credit-debit and currency model planned
`
`Copyright © 1995 University of Southern California
`
`33
`
`PayPal Ex.1016, p.33
`
`
`
`
`
`’s iKP proposal
`
`~:» iKP is a proposal for a family of public key
`protocols supporting secure presentation of
`credit card information.
`
`~:~ 1KP is similar to the CyberCash approach
`
`~:» ZKP adds authentication of the merchant
`
`oz» 3KP adds signature of the customer
`
`Copyright © 1995 Universiw of Southern California
`
`'
`
`34
`
`PayPal Ex.1016, p.34
`
`
`
`/ISI’s NetChequeSM
`
`~:» No prior arrangement between
`customer and merchant.
`
`«:« A check authorizes the payee to transfer
`funds from the payor’s account.
`
`»:» Multiple currencies per account.
`
`»:~ Payments clear through multiple
`payment servers.
`
`Copyright © 1995 University of Southern California
`
`V
`
`35
`
`PayPal Ex.1016, p.35
`
`
`
`copyright © 1995 University of Southern California
`
`%
`
`36
`
`PayPal Ex.1016, p.36
`
`
`
`
`
`«:» Important fields:
`
`-- Account and accounting server
`
`—— Amount, payee, expires
`
`— Memo: Customer info, merchant info
`
`—- Signatures and endorsements
`
`~:o MIME encoded for use by applications
`
`— Base 64 encoding for opaque part
`
`Copyright © 1995 University of Southern California
`
`37
`
`PayPal Ex.1016, p.37
`
`
`
`\/ heque: MIME Encoded
`
`~~NetCheque(SM)V1.0
`
`Content~Type: APPLICATION/X—NETCHEQUE
`
`Content—Transfer—Encoding: BASE64
`
`Content—DesCription: Pay 10.00 NCU to marketplace@NETCHEQUE.ISI.EDU
`
`AAAAAQAAAA5OzXRDaGvxdWvfvjEuMAAAAA1TT0zUv0FsRv9wMs4xAAAAAQED
`
`NTE4AzI2N2GCAQcwggEDoAMCAQWhExsRTkVUQOhFUVVFLklTSS5FRFWiKTAn
`
`oAMCAQGhIDAeGwlOZXRDaGVXdWUbEW5ldGNoZXFTZS5pc2kuZWRTo4G7MIG4
`
`oAMCAQGhAwIBAaKBqwSBqEILdnGDj8taheicu2b3DK+OqYB+ayEtyZUdVsyC
`
`RVFVRS5JUOkuRURVAAAABQAAAAIBMO5DVQEXATEAAAAEAjU5AAAACwk4MDAw
`
`MZQ4NzkJODAyMTk0Nzk4AAAACQIXNUNSaWZmb3JkXO5ldW1hbgAAAAEBMQEX
`
`AAAAHW1hcmt1dHBsYwN1QE5FVENIRVFVRs5JU0kuRURvAAAAAA==
`
`5-NetCheque(SM)V1.O-—
`
`Copyright © 1995 University of Southern California
`
`‘
`
`38
`
`PayPal Ex.1016, p.38
`
`
`
` > heque representation
`
`oz» Applications display checks according
`to their own requirements.
`
`— Display check makes it look like check
`
`— Statement displays one line per check
`
`«to Statement API returns entire check with
`
`endorsement
`
`— Allows easy import of information from
`check into users financial applications.
`
`Copyright © 1995 University of Southern California
`
`39
`
`PayPal Ex.1016, p.39
`
`
`
` = hequesecurity
`
`oz» Check hasplaintext part and signature
`oz» Endorsements are separately signed
`and linked to a particular check
`
`«to Signature component is modular
`
`—- Current implementation is Kerberos proxy
`
`Signature verifiable by customer's bank
`
`— Can accommodate RSA or DSS signatures
`
`Copyright © 1995 University of Southern California
`
`40
`
`PayPal Ex.1016, p.40
`
`
`
` hequeSm,
`
`Secure Applications
`
`Accounting and Electronic Commerce
`
`Dz'striburedA uthorization Mechanisms
`Authorization, Groups, Delegation, Capabilzfies
`
`Base A uthorigation Mechanism
`Restrzcted Proxzes
`
`Authentication Infiaszrucmre.’ Kerberos, X509
`
`Copyright © 1995 University of Southern California
`
`41
`
`PayPal Ex.1016, p.41
`
`
`
`ring the check itself
`
`
`
`check: [c1<no,am0unt,S]C %
`E1: [ckn0,am0unt,S]C [dep ckno to $1]S
`E2: [ckno,am0unt,S]C[dep ckno to $1]S[dep ckno t0$2]$1
`
`Copyright © 1995 University of Southern California
`
`42
`
`PayPal Ex.1016, p.42
`
`
`
`ingfunds through multipleservers
`
`AS3
`
`.. ccounts: AS_1, AS _
`
`\\
`
`\
`
`/
`
`/
`
`AS1
`
`AS2
`
`. ccounts: AS3,S1,CS
`
`.cc0unts: AS3,U2,CS I
`
`.
`I
`
`‘
`
`
`
`_A__S_2 Accounting Server
`
`_[__J: User
`
`S: Service Provider
`
`Copyright © 1995 University of Southern California
`
`43
`
`PayPal Ex.1016, p.43
`
`
`
`> hequestatus
`
`oz» Initial NetCheque release December 1994.
`
`~:~ Integration with WI/VI/Vybrowsers, and
`merchant support released May 1995,
`
`~:» NetCheque trial underway with play
`money [NCU=NetCheque Currency Unit)
`
`oz» NetCash to be available mid 1995
`
`«:~ Contact Information: NetCheque@isi.edu A
`
`-- URL: http: / / nii.isi.edu/ info / NetCheque
`
`Copyright © 1995 University of Southern California
`
`44
`
`PayPal Ex.1016, p.44
`
`
`
` ’s NetBill
`
`+:~ Supports credit-debit transactions
`
`~:~ Payment instrument is analogous to a check
`or credit card slip authenticated by Kerberos
`oz» Provides encrypted, atomic delivery of
`goods [described1ater)
`
`oz» Pilot scheduled for summer 1995
`
`Copyright © 1995 University of Southern California
`
`45
`
`PayPal Ex.1016, p.45
`
`
`
`’s Electronic Check
`
`«:+ Electronic check provides credit-debit payment
`instruments that can be sent across the Internet,
`but which clear through existing banking
`networks (e. g., ACH)
`
`~:« Instrument authenticated using public key
`i cryptography can digital signatures
`«:~ PCMCIA "electronic checkbook” protects keys
`
`+:» Preliminary demonstration scheduled fall 1995
`
`Copyright © 1995 University of Southern California
`
`45
`
`PayPal Ex.1016, p.46
`
`
`
`
`
`oz» Software implementation of electronic
`currency providing unconditional
`anonymity
`
`
`oz» On-—line detection of double spending
`
`«to Post—fact tracking of double spending
`
`Client software integrated with the Web
`»:« Pilot since 10/ 94 — CyberBucl<s
`
`Copyright © 1995 University of Southern California
`
`47
`
`PayPal Ex.1016, p.47
`
`
`
`/ISI’s NetCash5M
`
`oz» Users purchase currency from currency server
`using NetCheque - deposits to currency server’s
`account back the currency
`oz» Supports weakly anonymous payment
`
`—— Cash can be exchanged for new cash anonymously
`
`-- Customer chooses the currency server
`
`oz» Multiple currency servers, NetCheque used to
`clear cross-server payments
`
`Copyright © 1995 University of Southern California
`
`48
`
`PayPal Ex.1016, p.48
`
`
`
`
`
`'
`
`~ ymous payment using NetCash5M
`
`AS3
`
`accounts: AS1, AS2
`
`/’
`
`/
`
`/
`
`\
`
`\
`
`\
`
`N
`
`AS1
`
`AS2
`
`ccountsz AS3, U2,CS2
`
`ccounts: AS3, SLCS1
`
`If
`
`.
`
`
`_z_X_S_: Accounting Server
`§§:. Currency Server
`
`_U_: Usér
`
`_S_: Service Provider
`
`Copyright © 1995 University of Southern California
`
`49
`
`PayPal Ex.1016, p.49
`
`
`
`dex
`
`~:« Electronic currency for routine transactions
`oz» Currency can be accepted off-line
`
`Uses a tamper resistant smart card
`
`«z» Card signs transactions, so no anonymity
`
`«:~ Card-to-card transactions using "wa11et”
`
`Smartcard reader needed to use on network
`
`«:» Pilot scheduled for Summer 1995
`
`Copyright © 1995 University of Southern California
`
`50
`
`PayPal Ex.1016, p.50
`
`
`
`LIS
`
`Discuss requirements for network payment
`Understand kinds of payment methods
`
`Learn what systems are available
`
`at Discuss integration with applications
`
`Consider risks and discuss security
`
`Discuss role and rewards for providers
`
`Copyright © 1995 University of Southern California
`
`p
`
`51
`
`PayPal Ex.1016, p.51
`
`
`
`payment
`
`oz» Enable improvements and allocation of p
`resources to popular services.
`oz» Competition (including that from free A
`services] will keep prices down.
`oz» Encourages efficient use of resources.
`
`~:« Some services not available otherwise.
`
`Copyright © 1995 University of Southern California
`
`‘
`
`52
`
`PayPal Ex.1016, p.52
`
`
`
`
`
`it ents and applications
`
`«to Applications must support payment.
`
`»:~ Need thresholds for automatic payment.
`
`Confirmation for larger payments.
`
`~:» Feedback to users for current spending.
`
`Copyright © 1995 University of Southern California
`
`53
`
`PayPal Ex.1016, p.53
`
`
`
`y mi protocols
`
`~:~ Pay-Per-View
`
`«:« NetBi11
`
`»:» Open Market
`
`Copyright © 1995 University of Southern California
`
`54
`
`PayPal Ex.1016, p.54
`
`
`
`overview
`
`«to PPV is a payment protocol developed for
`use by NetCheque and NetCash.
`
`»:~ PPV is layered over web protocols and
`requires no changes to web browsers.
`
`oz» PPV is multi-mechanism, supporting other
`forms of payment instruments.
`
`»:+ PPV is a temporary measure until direct
`support for payment is provided.
`
`Copyright © 1995 University of Southern California
`
`55
`
`PayPal Ex.1016, p.55
`
`
`
`payment protocol
`
`»:~ Browser requests document from merchant.
`
`~:+ Merchant returns preview and payment
`information to browser
`
`oz» Browser connects to PPV client (a local
`HTTP server) and authorizes payment.
`
`v:» Client sends payment or information
`needed to retrieve payment to merchant.
`
`oz» Merchant returns document to browser.
`
`Copyright © 1995 University of Southern California
`
`55
`
`PayPal Ex.1016, p.56
`
`
`
`1,2
`
`3,4
`
`/
`
`/ /
`
`/
`
`3A,3B/ /
`
`6/)
`
`A
`I
`
`3D’3Cl
`
`
`
`Copyright © 1995 University of Southern California
`
`57
`
`PayPal Ex.1016, p.57
`
`
`
`document format
`
`«:«> Documents consist of
`
`-— Main document, and
`
`— Document header, including
`
`o Payee
`
`9 Price
`
`9 Payment methods accepted
`
`9 and more
`
`Copyright © 1995 University of Southern California
`
`58
`
`PayPal Ex.1016, p.58
`
`
`
` iew information
`
`~:~ Message passed from server to client
`
`- Sequence of paramzvalue pairs
`
`9 Payee
`
`o Price
`
`9 Payment methods accepted
`
`9 Return path
`
`Copyright © 1995 University of Southern California
`
`59
`
`PayPal Ex.1016, p.59
`
`
`
`
`
`em {or retrieval info)
`
`«:~ Message passed from client to server.
`—— Sequence of paramzvalue pairs
`o Payment method used
`
`0 Payment, or
`
`o Retrieval Information, including
`
`—-— Point of Contact
`
`-- Handle for payment instrument
`
`Copyright © 1995 University of Southern California
`
`(,0
`
`PayPal Ex.1016, p.60
`
`
`
`ter integration needed
`
`«t. Functionality currently uses CGI.
`oz» Fold scripts into HTTP server itself.
`— Port 1564 allocated for PPV
`
`oz» Browsers need to subsume scripts.
`oz» Confirmation should be distinguishable
`from remote web page.
`
`Copyright © 1995 University of Southern California
`
`51
`
`PayPal Ex.1016, p.61
`
`
`
` r integration with Mosaic
`
`oz» In-band negotiation for payment as as
`defined part of http:
`—— As an SHTTP extension, or
`
`—- As part of Secure Socket Layer
`
`Copyright © 1995 University of Southern California
`
`52
`
`PayPal Ex.1016, p.62
`
`
`
` 2 3 ration with Prospero
`
`oz» Payment information is part of security
`context and transmitted by ARDP
`
`oz» Payments negotiated in—band
`
`oz» Request for payment triggered by entry
`in access control list
`
`«:o Up-call allows client to approve and
`generate payment
`
`Copyright © 1995 University of Southern California
`
`53
`
`PayPal Ex.1016, p.63
`
`
`
`5ill integration overview
`
`»:» NetBill provides for the atomic exchange
`of information goods for payment.
`
`
`+:~ Minimal changes to Mosaic required,
`exchange with merchant is out-of-band.
`
`«z» Goods delivered to customer encrypted.
`
`'
`
`»:~ Key to decrypt goods provided after
`payment clears and additionally available
`through NetBi1l server.
`
`Copyright © 1995 University of Southern California
`
`54
`
`PayPal Ex.1016, p.64
`
`
`
` ill protocol
`
`1,2
`
`<4—————o—__..___.._..
`
`3,4
`-——----————-———--——---—-p
`4--—---—-———....——..........._......__......_....
`5,6
`————-—-————--—----—---—--—-————>
`<-—-------——-—---——-——-----—-
`
`————————--——-——-----——-—————-p;»
`<—————-——-._......_.._._j__
`
`7,10
`
`
`
`8,9 H
`
`Copyright © 1995 University of Southern California
`
`55
`
`PayPal Ex.1016, p.65
`
`
`
`
`
`Market overview
`
`oz» Open Market provides multi-mechanism
`collection services for web browsers.
`
`+:o Payment is made to Open Market
`payment switch.
`
`+:« Switch authorizes delivery of goods.
`
`«to Added value provided to customer
`through “smart statement”.
`
`Copyright © 1995 University of Southern California
`
`65
`
`PayPal Ex.1016, p.66
`
`
`
`
`
`Market protocol
`
` 1,2
`
`4--—————---—---————--————-V-———
`
`--—--——————-—-—-----——---->
`
`7,8
`
`3,-4,5,6
`
`Copyright © 1995 University of Southern California
`
`57
`
`PayPal Ex.1016, p.67
`
`
`
`rprise integration
`
`oz» Payment instruments and statements should
`include information allowing items to be
`used by internal financial applications.
`
`-— Accounts payable
`
`— Accounts receivable
`
`-- General ledger
`
`oz» Organizational controls should apply to
`payment authorization.
`
`Copyright © 1995 University of Southern California
`
`.58
`
`PayPal Ex.1016, p.68
`
`
`
`ment of NetCheque servers
`
`»:+ Banks and other fiduciaries
`-— To pay checks written against customer accounts.
`
`«:» Grantors of credit
`
`d
`
`—— Pay checks, and collect from customer later.
`
`«to Merchants
`
`— To track purchases on house accounts.
`
`+:» Customers
`
`— To allow checks to be cleared directly against
`a budget lines on customer’s books.
`
`Copyright © 1995 University of Southern California
`
`59
`
`PayPal Ex.1016, p.69
`
`
`
`
`= ation with banking system
`
`Modes of integration
`
`»:« Transactions gatewayed to banking system
`
`«z» Funds swept to and from banking system c
`
`«to Customersdeposit funds in advance
`
`~:» Customers pay periodic statements
`
`«to New currency with floating exchange rate d
`
`«to Barter
`
`Copyright ©_ 1995 University of Southern California
`
`70
`
`PayPal Ex.1016, p.70
`
`
`
`MS
`
`Discuss requirements for network payment
`
`Understand kinds of payment methods
`
`Learn what systems are available
`
`Discuss integration with applications
`<- Consider risks and discuss security
`
`Discuss role and rewards for providers
`
`Copyright © 1995 University of Southern California
`
`71
`
`PayPal Ex.1016, p.71
`
`
`
`risks of electronic commerce
`
`oz» The customer's perspective
`—-— Stolen payment credentials and passwords
`
`— Dishonest merchants
`
`-~—- Disputes over service quality
`--— Dishonest financial service providers
`
`—-— Inappropriate use of transaction details
`
`Copyright © 1995 University of Southern California
`
`D
`
`72
`
`PayPal Ex.1016, p.72
`
`
`
`risks of electronic commerce
`
`«t» The merchant's perspective
`
`-—- Forged or copied instruments
`
`— Disputed charges
`
`— Insufficient funds in customer account
`
`— Unauthorized redistribution of purchased items
`
`— Dishonest financial service providers
`
`- Slow payment by financial service provider
`
`p Copyright © 1995 University of Southern California
`
`i
`
`73
`
`PayPal Ex.1016, p.73
`
`
`
` risks ofelectronic commerce
`
`The financial service provider's perspective
`
`———- Deadbeat account holders
`—— Disputed charges to outside accounts
`
`— Disputed merchant charges
`
`—- Fly-by——night merchants
`
`—— Stolen customer or service credentials
`— Forged or copied instruments
`
`Copyright © 1995 University of Southern California
`
`V
`
`74
`
`PayPal Ex.1016, p.74
`
`
`
` <>:.-aading the risks
`
`«:« Limiting exposure to risk
`—- Credit VS. debit model for accounts
`
`—- Deferring payment to merchants
`
`Shifting risk to other parties
`—— Agreements shifting risk to merchant
`
`-- Regulations protecting the consumer
`
`-——- Insurance - perhaps as higher transaction fees
`
`Copyright © 1995 University of Southern California
`
`75
`
`PayPal Ex.1016, p.75
`
`
`
` nical solutions
`
`i
`
`oz» Protecting payment credentials
`
`-- Token cards
`
`
`
`— Smart cards
`
`»:« On—1ine authorization
`i~—- Detects double spending
`— Checks for sufficient funds
`
`-—-~ Enables checks for spending patterns
`
`~:» Tagging documents
`
`Copyright © 1995 University of Southern California A
`
`—
`
`76
`
`PayPal Ex.1016, p.76
`
`
`
`h Th'lSl'
`h‘
`\veryt mg asa ec ma:
`0 ution
`
`
`
`oz» There are problems where solutions can't be
`enforced in advance, but Where accepted
`practicessolve the problem if followed:
`——- Privacy protection and security safeguards
`
`- Intellectual property rights
`
`— Quality of service
`+:» These practices will usually be followed if:
`
`—-- It is easy to follow them
`
`—- There are consequences for ignoring them
`
`Copyright © 1995 University of Southern California
`
`77
`
`PayPal Ex.1016, p.77
`
`
`
`
`
`rance credentials
`
`oz» Certify service providers as following
`accepted practices or having the ability to
`cover losses
`
`
`- Surety—bonds
`
`- Business licenses
`
`-— Endorsements
`
`Certificates are stored as attributes in directory
`service or presented on first contact
`C
`
`«:o Used to select suitable service providers
`
`Copyright © 1995 University of Southern California
`
`.
`
`l 78
`
`PayPal Ex.1016, p.78
`
`
`
`<>rcy protection
`
`+:~ Application transport protocol carries:
`— User specified constraints on retention,
`dissemination, or use of audit records
`
`»:~ Merchant accepts or rejects:
`
`A
`
`Service provided
`— Accepts
`Error returned, no detail retained
`—- Rejects
`9 User can resubmit with fewer constraints
`
`«z» User sets default policy
`
`-- Applied to all requests
`
`Copyright © 1995 University of Southern California
`
`79
`
`PayPal Ex.1016, p.79
`
`
`
`1/[S
`
`Discuss requirements for network payment
`Understand kinds of payment methods
`
`Learn what systems are available
`
`Discuss integration with applications
`
`Consider risks and discuss security
`
`<- Discuss role and rewards for providers
`
`Copyright © 1995 University of Southern California
`
`'
`
`80
`
`PayPal Ex.1016, p.80
`
`
`
`ole offinancialserviceproviders
`
`«z» Possible roles include:
`
`-—- Trusted to hold our money
`
`-— Facilitate clearing of payments
`
`-—- Insure against fraudulent transactions
`
`Copyright © 1995 University of Southern California
`
`81
`
`PayPal Ex.1016, p.81
`
`
`
` 'rdsforfinancial service providers
`
`~:» Financial service providers recover their
`J expenses and make profits on:
`-— Account fees
`
`-— Transaction fees
`
`——- Currency exchange
`
`—- Interest charges [differential]
`
`—— Float
`
`Copyright © 1995 University of Southern California
`
`82
`
`PayPal Ex.1016, p.82
`
`
`
`iple financial service providers
`
`«:« If financial service providers compete on the
`basis of incompatible systems, payment
`services will be difficult to integrate and use.
`»:» Instead, multiple service providers will exist
`and it will be possible to clear payments
`between providers.
`
`
`«:» Designs for payment services should allow
`for multiple financial service providers.
`
`Copyright © 1995 University of Southern California
`
`83
`
`PayPal Ex.1016, p.83
`
`
`
`'ng the risks and rewards
`
`«z» Agreements will be needed to allocate risk
`between financial service providers.
`
`~:o Agreements on the splitting of fees will also
`be required.
`i
`
`.:« Service providers will compete on the basis
`of established trust, fees, and value added
`
` services.
`
`Copyright © 1995 University of Southern California
`
`l
`
`84
`
`PayPal Ex.1016, p.84
`
`
`
`Discussion
`
`»:~ Picking a solution
`
`-— ‘What’s available and when do you need it?
`
`—~ What are you selling?
`
`—— Who are your customers?
`
`—-— How much risk can you handle?
`
`«z» Security
`
`»:« Scalability
`
`Copyright © 1995 University of Southern California
`
`V
`
`85
`
`PayPal Ex.1016, p.85
Accessing this document will incur an additional charge of $.
After purchase, you can access this document again without charge.
Accept $ Charge
Still Working On It
This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.
Give it another minute or two to complete, and then try the refresh button.
A few More Minutes ... Still Working
It can take up to 5 minutes for us to download a document if the court servers are running slowly.
Thank you for your continued patience.
This document could not be displayed.
We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.
Your account does not support viewing this document.
You need a Paid Account to view this document. Click here to change your account type.
Your account does not support viewing this document.
Set your membership
status to view this document.
With a Docket Alarm membership, you'll
get a whole lot more, including:
- Up-to-date information for this case.
- Email alerts whenever there is an update.
- Full text search for other cases.
- Get email alerts whenever a new case matches your search.
One Moment Please
The filing “” is large (MB) and is being downloaded.
Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.
Your document is on its way!
If you do not receive the document in five minutes, contact support at support@docketalarm.com.
Sealed Document
We are unable to display this document, it may be under a court ordered seal.
If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.
Access Government Site
