U.S. patent application number 12/257212 was filed with the patent office on 2009-04-30 for escrow system and method.
Invention is credited to Patrick Faith, Ayman Hammad.
Application Number | 20090112767 12/257212 |
Document ID | / |
Family ID | 40580421 |
Filed Date | 2009-04-30 |
United States Patent
Application |
20090112767 |
Kind Code |
A1 |
Hammad; Ayman ; et
al. |
April 30, 2009 |
ESCROW SYSTEM AND METHOD
Abstract
A system and method for conducting purchasing transactions using
escrow. A central processing entity secures the terms to a
purchasing transaction on behalf of the various parties to the
transaction. Once the terms of the purchasing transaction are
agreed upon, the central processing entity holds any funds used in
the transaction in escrow until confirmation is received that a
supplier's contractual obligations have been fulfilled.
Inventors: |
Hammad; Ayman; (Pleasanton,
CA) ; Faith; Patrick; (Pleasanton, CA) |
Correspondence
Address: |
TOWNSEND AND TOWNSEND CREW LLP
TWO EMBARCADERO CENTER, 8TH FLOOR
SAN FRANCISCO
CA
94111
US
|
Family ID: |
40580421 |
Appl. No.: |
12/257212 |
Filed: |
October 23, 2008 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60982682 |
Oct 25, 2007 |
|
|
|
12257212 |
|
|
|
|
Current U.S.
Class: |
705/44 |
Current CPC
Class: |
G06Q 20/3274 20130101;
H04L 63/18 20130101; G06Q 40/00 20130101; G06Q 20/20 20130101; G06Q
20/3276 20130101; G06Q 40/128 20131203; G06Q 20/3223 20130101; G06Q
40/025 20130101; G06Q 20/40 20130101; G06Q 40/12 20131203; G06Q
20/3224 20130101; G06Q 20/387 20130101; G06Q 20/32 20130101; G06Q
30/0212 20130101; G06Q 20/102 20130101; G06Q 30/00 20130101; G06Q
20/10 20130101; G06Q 30/0601 20130101; G06Q 20/3825 20130101; G06Q
10/087 20130101; G06Q 30/0215 20130101; G06Q 20/401 20130101 |
Class at
Publication: |
705/44 |
International
Class: |
G06Q 40/00 20060101
G06Q040/00 |
Claims
1. A method for a payment transaction using a central processing
entity, the method comprising: receiving a purchase request message
from a consumer; sending to one or more suppliers a supply request
message; receiving from the one or more suppliers one or more
supply response messages; sending to one or more issuers a
financing request message; receiving from the one or more issuers
one or more financing response messages; selecting a supplier from
the one or more supply response messages and selecting one or more
issuers from the one or more financing response messages to form a
purchasing contract; sending an acceptance message to the selected
supplier and to the one or more selected issuers; receiving a set
of payments from the one or more selected issuers; holding the set
of payments in escrow until a confirmation is received; and
releasing the set of payments to the selected supplier after
receiving confirmation from the consumer.
2. The method of claim 1 wherein the purchase request message
includes one or more purchase parameters, wherein the purchase
parameters can be specific values or a range of values.
3. The method of claim 1 wherein the purchase request message
includes one or more financing parameters, wherein the financing
parameters can be specific values or a range of values.
4. The method of claim 1 wherein the supply request message or the
financing request message includes information from a consumer
profile created by the consumer, wherein the consumer profile
contains information on the consumer's purchasing or financing
preferences.
5. The method of claim 1 wherein the supply request message
includes information from more than one purchase request
message.
6. The method of claim 1 wherein the financing request message
includes information about the one or more supply response
messages.
7. The method of claim 1 further comprising: generating a risk
assessment associated with the purchase request.
8. The method of claim 7 wherein the risk assessment includes a
fraud risk assessment and a credit risk assessment.
9. The method of claim 7 wherein the financing request message
includes the risk assessment.
10. The method of claim 1 wherein the one or more issuers are
issuers that hold credit or debit accounts of the consumer.
11. The method of claim 1 wherein the one or more financing
response messages include options to use reward points earned by
the consumer.
12. The method of claim 1 wherein the step of selecting a supplier
and selecting one or more financers is done by the consumer.
13. The method of claim 1 wherein the step of selecting a supplier
and selecting one or more financers is done by the central
processing entity.
14. The method of claim 1 wherein the confirmation is generated by
the consumer.
15. The method of claim 1 wherein the confirmation is generated by
a shipping entity.
16. A computer-readable medium comprising code for performing the
method of claim 1
17. A server computer with a processor and the computer-readable
medium of claim 16.
18. A method for purchasing goods using a central processing
entity, the method comprising: sending a purchase request message
to the central processing entity, wherein the central processing
entity uses the purchase request message to collect a set of supply
offers from one or more supplier and to collect a set of financing
offers from one or more financers; accepting one or more selected
supply offers from the set of supply offers and one or more
selected financing offers from the set of financing offers to form
a purchase contract, wherein creation of the purchasing contract
causes the central processing entity to place a set of payments
derived from the one or more selected financing offers into escrow
with the central processing entity; and sending a confirmation that
a supplier has fulfilled its obligations under the purchasing
contract to the central processing entity, wherein the confirmation
causes the central processing entity to release the set of payments
in escrow to the supplier.
19. A computer readable medium comprising: code for sending a
purchase request message to the central processing entity, wherein
the central processing entity uses the purchase request message to
collect a set of supply offers from one or more supplier and to
collect a set of financing offers from one or more financers; code
for accepting one or more selected supply offers from the set of
supply offers and one or more selected financing offers from the
set of financing offers to form a purchase contract, wherein
creation of the purchasing contract causes the central processing
entity to place a set of payments derived from the one or more
selected financing offers into escrow with the central processing
entity; and code for sending a confirmation that a supplier has
fulfilled its obligations under the purchasing contract to the
central processing entity, wherein the confirmation causes the
central processing entity to release the set of payments in escrow
to the supplier.
20. A computer apparatus comprising a processor, and the computer
readable medium of claim 19 coupled to the processor.
Description
CROSS-REFERENCES TO RELATED APPLICATIONS
[0001] This patent application claims priority to U.S. Provisional
Application No. 60/982,682 filed Oct. 25, 2007, entitled "Mobile
Phone Payment System and Method," which is hereby incorporated by
reference in its entirety for all purposes.
BACKGROUND
[0002] A consumer, using prior methods, could negotiate the
purchase an item from a merchant or manufacturer. The consumer
could negotiate with the seller over the item to be purchased, the
price of the item, as well as other terms of the transaction. Once
an agreement was reached, a consumer could conduct a payment
transaction using a credit account.
[0003] This standard purchasing scenario presented some drawbacks
for consumers. Typically, a consumer could only communicate with
one merchant or manufacturer at a time. Consequently, merchants and
manufactures were often not in direct competition with each other.
Also, the consumer did not have financers competing over credit
terms. As a result, consumers were often not receiving the best
possible financing deals for their purchases.
[0004] The typical purchasing scenario also presented some problems
for merchants. For example, when purchasing transactions are
conducted over the Internet, the merchant is typically the entity
that bears the financial risk if the consumer is unable to pay for
the purchased item. As a result, merchants and manufacturers were
often hesitant to give their best deal online because they had to
incorporate into any offered price the credit risk of the
consumer.
[0005] Issuers that offered financing terms often encountered a
risk similar to the risk faced by merchants. For example, when a
consumer purchases an item in person, perhaps using a point-of-sale
terminal at a retailer, the issuer bears the risk if the consumer
fails to pay off the debt. As a result, issuers have to price into
their financing terms this assumed risk for these transactions.
[0006] Embodiments of this disclosure address these and other
problems.
SUMMARY
[0007] Embodiments of the invention are directed to methods and
systems suitable for processing transactions.
[0008] One embodiment is a method for a payment transaction using a
central processing entity. The method comprises receiving a
purchase request message from a consumer, sending to one or more
merchants a supply request message, receiving from the one or more
merchants one or more supply response messages, sending to one or
more issuers a financing request message, receiving from the one or
more issuers one or more financing response messages, selecting a
supplier from the one or more supply response messages and
selecting one or more issuers from the one or more financing
response messages to form a purchasing contract, sending an
acceptance message to the selected supplier and to the one or more
selected issuers, receiving a set of payments from the one or more
selected issuers, holding the set of payments in escrow until a
confirmation is received, and releasing the set of payments to the
selected supplier after receiving confirmation from the
consumer.
[0009] In another embodiment is method for purchasing goods using a
central processing entity. The method comprises sending a purchase
request message to the central processing entity. The central
processing entity uses the purchase request message to collect a
set of merchandise offers from one or more merchants and to collect
a set of financing offers from one or more financers. An offer is
accepted from the set of offers, and an offer is accepted from one
or more selected financing offers from the set of financing offers
to create a purchasing contract. The creation of the purchasing
contract causes the central processing entity to place a set of
payments derived from the one or more selected financing offers
into escrow with the central processing entity. A confirmation that
a merchant has fulfilled its obligations under the purchasing
contract is sent to the central processing entity. The confirmation
causes the central processing entity to release the set of payments
in escrow to the merchant.
[0010] These and other embodiments are described in further detail
below, with reference to the Figures.
BRIEF DESCRIPTION OF THE DRAWINGS
[0011] FIG. 1 is a block diagram of an exemplary system for
conducting a payment transaction using escrow, in accordance with
an embodiment of the disclosure.
[0012] FIG. 2 is a flowchart illustrating a method for conducting a
payment transaction using escrow, in accordance with an embodiment
of the disclosure.
[0013] FIG. 3 is an illustration depicting an exemplary
user-interface, in accordance with an embodiment of the
disclosure.
[0014] FIG. 4 is an illustration depicting an exemplary
user-interface, in accordance with an embodiment of the
disclosure.
[0015] FIG. 5 is an illustration depicting an exemplary
user-interface, in accordance with an embodiment of the
disclosure.
DETAILED DESCRIPTION
[0016] Embodiments of the invention are directed to a method and a
system for conducting purchase transactions through a central
processing entity through escrow.
[0017] One aspect of the disclosed systems and methods is that a
central processing entity sits in the middle to parties conducting
a purchasing transaction, such as a consumer, a merchant, and an
issuer. In one embodiment, the central processing entity is a
payment processing organization that operates a payment processing
network, the payment processing network itself, or any subcomponent
thereof. All parties can deal with the central processing entity
and not directly with the other parties. As a result, a number of
benefits can be obtained for all parties.
[0018] As used herein, "payment processing organization" may refer
to an organization that runs the payment processing network, or it
may refer to any other suitable entity that deals with or processes
payments. A "payment processing network" may include any suitable
collection of computational apparatuses that can process payment
information. In some embodiments, a payment processing network may
be adapted to process credit and debit card transactions. More
specifically, it may be able to send and receive authorization
request messages for debit and credit card transactions, and may be
able to clear and settle such transactions.
I. Exemplary System for Conducting a Payment Transaction Using
Escrow
[0019] FIG. 1 is a block diagram of an exemplary system 100 for
conducting a payment transaction using escrow, in accordance with
an embodiment of the invention. System 100 includes a consumer 110
using a communication device 120 that is in operative communication
with a payment processing network 130. The system 100 also includes
suppliers 140 (e.g., supplier A 140(a) and supplier B 140(b)) and
issuers 150 (e.g., issuer A 150(a) and issuer B 150(b)). The
suppliers 140 and the issuers 150 are also in operative
communication with the payment processing network 130. Any suitable
number of suppliers 140 and issuers 150 may be present in systems
according to embodiments of the invention.
[0020] Consumer 110 may be an individual, or an organization such
as a business that is capable of using a communication device 120
to conduct a payment transaction. A payment transaction can be any
exchange of services or goods. Consumer 110 will typically have
credit accounts and debit accounts with one or more of the issuers
140. The credit and debit accounts of a consumer 110 can be
associated with one or more communication devices 120.
[0021] A communication device 120 can refer to any suitable device
that allows consumer 110 to communicate a payment processing
organization 120 to conduct a payment transaction with suppliers
130 and issuers 140. Some examples of communication devices include
computer apparatuses (e.g., laptop computers, desktop computers,
etc.), cellular or wireless phones, personal digital assistants
(PDAs), pagers, smart media, and the like. Communication devices
can be hand-held and compact so that they can fit into a consumer's
wallet and/or pocket (e.g., pocket-sized).
[0022] Communication device 120 is a capable of communicating
information in any suitable form. For example, some communication
devices 120 may communicate with a payment processing organization
120 by sending messages over the Internet. Other communication
devices 120 may use a short message service (SMS) message such as a
text message, a multimedia media message (MMS), a phone call, a
voice message, a voicemail message, an instant messaging (IM)
message, an email message, etc.
[0023] In some cases, an entity receiving a message from a
communication device 120 (e.g., payment processing network 130) may
require a PIN for security purposes before authorizing the
transmission. Consumer 110 can enter the PIN into communication
device 120 communicating with the entity. The communication device
120 can then send the PIN to the entity. Once the entity verifies
the PIN, the requesting entity will authorize the transmission of
the message. For example, to send a SMS message to payment
processing network 130, payment processing network 130 may request
a PIN that must be verified as a valid PIN before allowing the
transmission of the SMS message.
[0024] In some embodiments, the communication device 120 may
interact with other entities indirectly. For example, in one
embodiment, the communication device 120 may interact with a
payment processing network 130 by first communicating with an
access device, such as a point-of-sale terminal, that in turn
communicates with the payment processing network 130.
[0025] If an access device is a point of sale terminal, any
suitable point of sale terminal may be used including card or phone
readers. The card or phone readers may include any suitable contact
or contactless mode of operation. For example, exemplary readers
can include RF (radio frequency) antennas, magnetic stripe readers,
etc. to interact with the portable consumer devices.
[0026] In some embodiments, communication devices 120 may include
specialized software that allows the communication device 120 to
communicate directly other entities. For example, a communication
device 120 in the form of a mobile phone may include translation
software that translates transaction information received from an
access device into a form that can be understood, processed, and
transmitted by payment processing network 130.
[0027] In some embodiments, communication devices 120 may use
generalized software to allow the device to communicate with other
entities. For example, a communication device 120 in the form of a
computer may use a standard web browser to communicate with a
payment processing network 130 over the Internet. The payment
processing network 130 may run a web site that receives, processes,
and responds to messages received over the Internet.
[0028] Suppliers 140 can include any entity that can supply the
goods or service that a consumer may wish to purchase. Some
examples of suppliers include manufacturers of goods, providers of
services, or retailers. Suppliers 140 can communicate with a
payment processing organization using any suitable method to
conduct a payment transaction. For example, supplier 140 may use an
e-commerce business application to conduct a transaction over the
Internet by communicating with a payment processing
organization.
[0029] Issuers 150 can include entities that may open and maintain
an account for a consumer 110. Such issuer 150 may or may not have
a pre-existing relationship with the consumer 110. For example,
issuer A 150(a) may have issued a credit card to the consumer 110,
but issuer B 150(b) may not have done so. Some examples of issuers
include banks, business entities such as retail stores, or
governmental entities. In many cases, issuer 150 may also issue a
payment card to a consumer 110.
[0030] A payment processing network 130 may include data processing
subsystems, networks, and operations used to support and deliver
authorization services, exception file services, and clearing and
settlement services. An exemplary payment processing network 130
may include VisaNet.TM.. Payment processing networks such as
VisaNet.TM. are able to process credit card transactions, debit
card transactions, and other types of commercial transactions.
VisaNet.TM., in particular, includes a VIP system (Visa Integrated
Payments system) which processes authorization requests and a Base
II system which performs clearing and settlement services.
[0031] In one embodiment, the payment processing network 130
includes a value-added services engine (VASE) 131. A VASE 131 is an
engine, often written in software running on a server computer,
capable of facilitating communications and transactions between
consumers 110, suppliers 140, and issuers 150. In addition, a VASE
can provide a number of services for each of the parties involved
in a payment transaction. For example, VASE 131 is capable of
interacting with a fraud risk module 132 and a credit risk module
133 to create a risk analysis of the consumer 110. This risk
analysis can be given to suppliers 140 and issuers 150 to help
suppliers 140 and issuers 150 decide what terms they will offer to
the consumer 110 in a payment transaction. VASE 131 is also capable
of using an escrow module 134 to hold consumer 110 funds received
from an issuer 150 until the consumer 110 confirms that a supplier
140 has fulfilled their obligations to the consumer 110 in a
payment transaction.
[0032] A VASE 131 may be run on a computer or a server computer. A
server computer refers to a powerful computer or cluster of
computers. For example, the server computer can be a large
mainframe, a minicomputer cluster, or a group of servers
functioning as a unit. In one example, server computer may be a
database server coupled to a web server. VASE 131 may use any
suitable wired or wireless network, including the Internet. A
server computer can include a computer readable medium (CRM). CRM
comprises code for performing the functions of server computer.
Server computer may also include a processor (not shown).
[0033] VASE 131 may also include a database. A database may store
any suitable data. For example, a database may include data that
links information associated with a communication device 120 (e.g.,
phone number) to account numbers and other information of consumer
110. Database also includes data that links consumer data (e.g.,
account numbers) to issuers 150.
[0034] Escrow module 134 is a module that may be present in a
payment processing network 130. One purpose of the escrow module is
to hold a consumer's 110 funds received from an issuer 150 in
escrow until a supplier 140 completes their obligations of payment
transaction. In one embodiment, a consumer 110 can notify a payment
processing network 130 that the consumer 110 has received delivery
of the items purchased from the supplier 140. After a payment
processing network 130 receives this notification, the payment
processing organization can use the escrow module 134 to release
the stored funds to the supplier 140. In one embodiment, the
payment processing organization releases the funds to the supplier
140 by crediting the funds to an account of the supplier 140. The
escrow module 134 may be run on a computer or a server computer.
The escrow module 134 may have access to a database to store
information. The escrow module 134 may be able to communicate with
a VASE 131.
[0035] Fraud risk module 132 is a module that may be present in the
payment processing network 130. The fraud risk module 132 is able
to collect and analyze data concerning a consumer 110 to determine
the risk that a request received by the payment processing network
130 from a consumer 110 is fraudulent. For example, one embodiment
of a fraud risk module 132 may analyze the location from where the
request of the consumer 110 originated. The fraud risk module 132
can compare the location to other data, such as the home or
business address of the consumer 110. The fraud risk module 132 may
then assign or adjust a fraud risk score based on the comparison of
this location information. Other factors could also be used by a
fraud risk module to determine a fraud risk score. For example, a
fraud risk module might analyze the value of the transaction, the
order history of the consumer, the communication medium or protocol
used to transmit the purchase transaction request, the shipping
parameters in the request, the time of day the request was made,
the location from which the request was made, whether the request
was authenticated using a PIN, etc. The fraud risk analysis can
then be shared with issuers 150 and suppliers 140 so that those
entities may use the fraud risk analysis when forming responses to
a consumer's request to purchase or finance goods or services.
[0036] Credit risk module 133 is a module that may be present in
the payment processing organization. The credit risk module 133 can
be configured to analyze a consumer's credit history in the context
of a given payment transaction to determine the potential risk that
a consumer 110 will not be able to fulfill any payment obligations
for the given transaction. For example, if a consumer has
frequently made late payments on a credit account that is being
used in a given payment transaction, then the credit risk module
133 can assign a higher credit risk score to for that transaction.
Other credit risk factors may include the percent of the credit
limit current used by a consumer, the number of credit accounts
opened by the consumer, the length of the consumer's credit
history, etc. The credit risk analysis can then be shared with
issuers 150 and suppliers 140 so that those entities may use the
credit risk analysis when forming responses to a consumer's request
to purchase or finance goods or services.
[0037] The following patents and applications can describe suitable
fraud risk modules or aspects thereof, and they are herein
incorporated by reference in their entirety for all purposes: U.S.
patent application No. 10/863,813, filed on Jun. 7, 2004, U.S. Pat.
No. 6,119,103, issued Sep. 12, 2000, entitled "Financial Risk
Prediction Systems and Methods Therefor," U.S. Pat. No. 6,658,393,
issued Dec. 2, 2003, entitled "Financial Risk Prediction Systems
and Methods Therefor," and U.S. Patent Application Publication No.
2002/0194503, published Dec. 19, 2002, entitled "Distributed
Quantum Encrypted Pattern Generation and Scoring.
II. Exemplary Method for Conducting a Transaction Using Escrow
[0038] FIG. 2 is a flow chart illustrating the steps taken
according to one embodiment. Many of the entities in FIG. 1 will be
referenced in the description of the steps outlined in FIG. 2.
[0039] At step 201 a consumer 110 initiates a payment transaction
by sending a purchasing request message to a payment processing
network 130. The purchasing request message may include parameters
for the items or services that the consumer wishes to purchase. In
one embodiment, a consumer 110 may use a communication device 120
to enter the initial parameters for the payment transaction. In
various embodiments, the initial parameters may include the
particular items the consumer wishes to purchase, features related
to any of the requested items, the desired price range, delivery
terms, financing terms, etc. Parameters related to the goods or
services to be purchased can be considered purchase parameters.
Parameters related to the financing terms desired by the consumer
can be referred to as financing parameters.
[0040] A consumer 110 may also select a consumer profile at step
201 for use in a given payment transaction. In one embodiment, a
consumer profile is configured by a consumer 110 to reflect various
preferences that the consumer 110 may wish to use for a class of
payment transactions. For example, a consumer may create a profile
named "electronics" that contains preferences for transactions
involving electronics. This profile may reflect the consumer's
preference for weekend home delivery of electronic items. The
consumer may also prefer to use certain credit accounts when
purchasing electronics, because those credit accounts give extra
insurance or warranty benefits for items purchased using those
credit accounts. A consumer 110 may create many different profiles.
For example, a consumer may also have a profile named "automotive"
in addition to an "electronics" profile. In the "automotive"
profile, the consumer may wish to minimize the interest rate used
for purchases related to automobiles. One skilled in the art will
recognize that there are many different permutations of preferences
that a consumer could express through the use of consumer
profiles.
[0041] Once a consumer 110 has selected the desired parameters for
a transaction, the parameters are communicated to the payment
processing network 130 in a purchase request message. As discussed
earlier, a communication between a consumer 110 and a payment
processing network 130 may be transmitted in a variety of ways. For
example, a communication device 120 used by the consumer can
transmit the purchasing request message to the payment processing
network 130 over the Internet.
[0042] At step 202, the payment processing network 130, or a
subcomponent thereof, may conduct risk assessment of the consumer's
requested purchase transaction. Conducting a risk assessment is
optional. In various embodiments, a fraud risk module may be used
to create a fraud risk score reflecting the probability that the
received transaction request is fraudulent. In various embodiments,
a credit risk module may be used to create a credit risk score
reflecting the probability that a consumer will not be able to pay
for the items or services requested in the payment request message.
As discussed earlier in reference to the fraud risk module and the
credit risk module, a variety of factors may be considered by each
module to determine their respective risk scores. Also, some
embodiments may combine a credit risk score and a fraud risk score
into a single risk score.
[0043] At step 203, after it receives the purchase request message,
the payment processing network 130 sends (e.g., transmits) supply
request messages to suppliers 140. The supply request message can
contain many pieces of data. For example, the supply request
message can identify the goods or services that the consumer 110
wishes to purchase. The supply request message may also contain
other purchase parameters sent to the payment processing network
130 from the client 110. Other data, such as the outcome of any
credit risk or fraud risk analysis can also be transmitted to the
suppliers 140 in a supply request message.
[0044] In some embodiments, a payment processing network 130 may
aggregate many similar purchase requests received from different
consumers 110. The payment processing network 130 (or a server
computer present therein) may aggregate these purchase requests
into a single supply request message to each of the suppliers 140.
One potential advantage for consumers in this scenario is that
consumers may be able to get better terms from supplier when the
goods or services are purchased in bulk in combination with other
consumers.
[0045] Illustratively, ten different consumers may send purchase
requests to buy the same type of television. The payment processing
network 130 can aggregate those purchase requests and can send an
aggregate supply message to one or more of the suppliers 140.
Because the supply message may request the purchase of ten
television sets instead of one television set, one or more of the
suppliers 140 may be willing to provide a greater discount on the
bulk sale of television sets.
[0046] In some embodiments, consumers 110 may elect to participate
in an aggregated purchase request while selecting the parameters
for a transaction. In other embodiments, consumers may indicate in
their profile that they are willing to participate in aggregated
purchases if available. In yet other embodiments, the payment
processing network 130, may suggest to a consumer that they join an
aggregated purchase request if the consumer submits a purchase
request similar to an aggregated purchase request already in
progress.
[0047] A payment processing network 130 may also run different
aggregated purchases in different manners. For example, a payment
processing network may allow consumers 110 to join an aggregated
purchase request until a certain number of purchase requests have
been received. The target number of requests may be 10, 100, 1000,
etc. Alternatively, a payment processing network may collect
purchase orders until the anticipated aggregate value of the
purchase orders crosses a threshold value. Other embodiments may
collect purchase orders until a certain date has passed or a
certain amount of time has elapsed. It is also possible to combine
these variations. For example, an aggregated purchase request may
remain open until 100 orders have been collected or one week has
passed. In some embodiments, consumers may be able to opt-out of an
aggregated purchase request if the period to join the aggregated
purchase request is still open. In any of these embodiments, the
payment processing network may send out a notification to any
consumers who have joined the aggregated purchase request in order
to give the consumers updates on the status of the purchase request
or to inform the consumers that the opportunity to opt in or out of
a purchase request will soon pass.
[0048] In some embodiments, an aggregated purchase request may be
managed by a VASE 131 and information related to the aggregated
purchase request may be stored in associated databases. In other
embodiments, a separate module may manage the aggregated purchase
request on behalf of the VASE 131.
[0049] In some embodiments, the payment processing organization
that operates or is affiliated with the payment processing network
130 is the entity actually buying the goods or services from the
supplier 140, not the consumer 110. As a result, if the consumer
100 backs out of a purchase transaction after an agreement has been
reached, then the payment processing organization that operates or
that is affiliated with the payment processing network 130 owns the
goods or services and is responsible for payment.
[0050] At step 204, suppliers 140 send supply response messages to
the payment processing network 130. Suppliers 140 can include in
their supply response messages any offers that they feel is
appropriate. A supplier 140 may include multiple offers in response
to a single supply request message, or a supplier 140 may decline
to make any offer.
[0051] At step 205, offers for financing from one or more issuers
150 are solicited from the payment processing network 130 in a
financing request message. A financing request message may contain
the parameters of the consumer's negotiation request, any risk
analysis conducted by the payment processing organization, or other
relevant data. For example, in some embodiments the offers received
from the suppliers 140 may also be presented to the issuers 150 for
their evaluation. Issuers 150 may wish to make any financing offers
for specific suppliers 140 or even specific offers made by
suppliers 140.
[0052] In some embodiments, it may be beneficial for a consumer 110
to receive financing for a payment transaction from more than one
issuer 140. For example, one issuer 140 may be able to offer an
very low interest rate on a loan, but this low interest rate is
only available up to a maximum amount that is below the value for a
given transaction. If a consumer 110 wishes to minimize the overall
interest rate on any funds borrowed used to conduct a transaction,
it may be beneficial for a consumer to combine the capped low
interest rate offer from one issuer with another financing offer
from a different issuer in order to obtain the best overall
financing. Thus, a single transaction may be financed by multiple
issuers in some embodiments of the invention.
[0053] In some embodiments, the financing may not be strictly on
cash terms. For example, the consumer 110 may have a credit account
with an issuer 150 with a rewards program, and the issuer, in its
offer, may allow the consumer to finance the purchase, in whole or
in part, with reward points previously earned by the consumer
110.
[0054] In some embodiments, the payment processing organization
that operates the payment processing network 130 is the entity
securing financing for the payment transaction from an issuer 140,
not the consumer 110. As a result, it is the payment processing
organization that must pay back the issuer if the consumer fails to
pay for the purchase transaction. Issuers may offer the payment
processing network better financing terms than a consumer because
the fraud and/or credit risk to the issuer is often lower when
offering financing to a payment processing network than a
consumer.
[0055] In some embodiments, the financing may obtained in an
aggregated manner. For example, a number of consumers 110 may have
credit accounts with similar issuers 150, and the payment
processing network 130 may present these financing requests to the
issuers in an aggregated fashion similar to the aggregated purchase
requests discussed earlier.
[0056] At step 206, offers from one or more issuers are received by
the payment processing network 130 in a financing response message.
Issuers 150 are free to make any numbers of offers in response to a
give financing request message.
[0057] At step 207, one or more offers from the suppliers 140 and
the issuers 150 are selected by the consumer 110 to form a
purchasing contract. In one embodiment, the offers submitted by the
suppliers 140 and issuers 150 are presented to the consumer 110,
and the consumer 110 accepts one or any combination of the offers
that the consumer finds most appealing. In some embodiments, the
payment processing network 130 groups a supplier's offer with an
issuer's offer before presenting the combined offers to the
consumer 110. The combined offers may be presented to the consumer
110 via a Web interface. In another embodiment, the payment
processing organization has the authority to select offers on
behalf of the consumer within specified parameters. In various
embodiments, the suppliers and issuers are notified by using
acceptance messages. The one or more accepted supply offers and the
one or more accepted financing offers can be considered a set of
accepted offers.
[0058] At step 208, the payment processing network 130 collects the
funds from the issuers 150 of any selected financing offers and
places those funds from into escrow. In one embodiment, an escrow
module 134 is used to store and track the funds. The one or more
selected financing offers can be considered a set of payments.
[0059] At step 209, the suppliers 140 of any selected offers are
notified that their offers have been accepted by a consumer 110.
Once a supplier 140 is notified that its offer has been accepted,
the supplier is aware that it has entered into a contract with the
consumer and the supplier can begin to fulfill the terms of the
contract.
[0060] At step 210, the consumer 110 confirms to the payment
processing network 130 that a supplier 140 has completed its
obligation to the consumer under the purchasing contract. The
precise obligations of the supplier 140 will depend on the
contract. In one embodiment, the consumer 110 will confirm (e.g.,
in a confirmation message) that he has received satisfactory
delivery of the items the consumer 110 has purchased from the
supplier 140. The consumer 110 may sent his confirmation to the
payment processing network 130 using the same communication device
120 the consumer used to create the purchasing request message. The
consumer 110 may alternatively use a different device to send its
confirmation. In some embodiments, the consumer may send an email,
SMS, or other message to the payment processing organization to
confirm that the supplier has fulfilled their obligations. In some
embodiments, the payment processing organization may send a
communication to the consumer 110 asking the consumer 110 to
confirm that that supplier 140 has fulfilled its obligations. This
message may be sent via email, SMS, or any other appropriate means.
In another embodiment, confirmation may not be sent by the
consumer; instead, confirmation is sent to the payment processing
organization by a third-party, such as a shipping entity,
freighter, or installation service.
[0061] In the event that the consumer 110 fails to send a timely
confirmation, the payment processing network 130 may wish to seek
independent confirmation that a supplier 150 has fulfilled their
obligations.
[0062] At step 211, the funds held in escrow are released to the
supplier 140 after the consumer's 110 confirmation is received by
the payment processing network 130. The funds can be transferred to
the supplier in a variety of ways. For example, a check can be
mailed, funds can be wired to an account owned by the supplier,
etc. In another embodiment, an acquirer, such as a bank that
operates a bank account for the supplier, receives the released
funds on behalf of the supplier. An acquirer refers to any suitable
entity that has an account with supplier. Once step 211 is
complete, the transaction is complete.
[0063] FIGS. 3-5 show examples of user-interfaces that a consumer
110 might use according to one embodiment. The illustrations shown
in FIG. 3-5 resemble screen shots of a generic web browser that can
be used to communicate with a payment processing network 130. It
will be clear to one of skill in the art that the interfaces shown
in FIG. 3-5 can easily be adapted to for a variety of communication
devices 120. For example, the screen, or slight variants thereof,
could be displayed on a computer, on a mobile phone, at a POS
device, etc.
[0064] FIG. 3 shows an example of a screen a consumer 110 might use
to enter parameters for a negotiation transaction that the consumer
wishes to conduct. FIG. 3 corresponds to step 201 in FIG. 2. In
FIG. 3, a consumer is presented with a form that presents a number
of different options that a consumer can use to specified the
consumer's desired criteria for a purchase transaction. The
parameters in the embodiment shown in FIG. 3 include the type of
item to purchase 310, a specific feature of the item 320, a desired
price range 330, a delivery preference 340, financing preferences
350, and a selected user profile 350. In the example shown in FIG.
3, the consumer 310 wishes to purchase an LCD television for
between $2000.00 and $2500.00. The consumer has also specified that
delivery should be by Aug. 30, 2008 and that no specific financing
terms are preferred. Also, the user has selected an "Electronics"
user-profile that the consumer has configured. As described above,
this profile may specify additional criteria relevant to this
negotiation request. When the consumer clicks on the submit button,
a purchase request message is sent to a payment processing network
130.
[0065] FIG. 4 shows an example of how one embodiment presents to a
consumer 110 a number of offers received from suppliers 140 and
issuers 150. FIG. 4 corresponds to step 207 in FIG. 2. In FIG. 4, a
payment processing organization operating a payment processing
network 130 has taken the information given to the payment
processing organization by the consumer in FIG. 3 and obtained a
number of offers for goods and financing. These offers have been
grouped by the payment processing organization and are presented to
the consumer in FIG. 4. Other embodiments may present the offers
for merchandise separately from the offers for financing.
[0066] In FIG. 4, a number of offers from various suppliers 140 and
issuers 150 can be seen. For example, "Offer #1" 410 presents a
42'' LCD with 1080 p from Brand X for $2000.00. "Offer #2" 420
presents a 46'' LCD with 1080 p from Brand Y for $2150.00. FIG. 4
also shows a number of different financing options associated with
these offers. For example, "Offer #1" uses credit card A of the
consumer and offers 0% financing for 60 days and 15.5% thereafter.
"Offer #2" includes a financing offer using credit card B for 8.9%
interest. "Offer #3" 430 offers for the user to use 100,000 reward
points that the consumer has earned with that account.
[0067] In the example shown in FIG. 4, the consumer 110 has
selected Offer #2 420 as his preferred offer. When the consumer
clicks the submit button, the payment processing network 130 will
secure the appropriate funds from the issuer 150 holding "Credit
Card B" and send a message to the supplier 140 of the television to
send the goods to the consumer.
[0068] FIG. 5 shows an example of a user-interface that a consumer
110 might use to confirm that a supplier 140 has fulfilled their
obligations. FIG. 5 corresponds to step 210 in FIG. 2. In this
screen, a consumer is confirming that the consumer has received the
item purchased. The payment processing network 130 may then release
consumer funds held in escrow to the supplier.
[0069] Embodiments of the invention provide for a number of
advantages. One advantage to a consumer is increased competition
among merchants and issuers. As a result, consumers should be able
to secure better deals for purchases and financing. Another benefit
may be that the central processing entity will be able to aggregate
purchase requests from a number of consumers and present those
aggregated purchase requests to sellers and issuers so as to secure
better terms for consumers.
[0070] One advantage to merchants in some embodiments is that,
since they are actually selling to the central processing entity,
rather than the consumer, the credit risk for any transaction is
minimal. Also, the central processing entity can hold funds that
are to be used to pay for any purchases in escrow. As a result, a
merchant can feel more secure about any transactions conducted with
a central processing entity because the merchants know that the
funds are available as soon as the merchants complete their
obligations under a purchase contract. Additionally, embodiments
allow merchants to incorporate real-time information, such as
inventory, into any offers for sale that they make.
[0071] Issuers are also able to benefit from aspects of the
disclosed systems and methods. For example, issuers can be
presented with a variety of information that they can use to
determine the financing terms that they will offer on a transaction
by transaction basis. Also, issuers can feel more secure about
being paid for any credit they offer, because it is the central
processing agency buying goods from merchants.
[0072] Certain embodiments of the invention may include none, some,
or all of the above technical advantages. One or more other
technical advantages may be readily apparent to one skilled in the
art from the figures, descriptions, and claims included herein.
III. Alternative Embodiments
[0073] The process outlined in FIG. 2 describes a general
embodiment. There are many variations of the general flow outlined
in FIG. 2 that might be appropriate for other embodiments.
[0074] One alternative embodiment is a fast escrow embodiment. In
this embodiment, the entire process is designed to occur over a
very short period of time similar to a typical purchase made using
any typical Internet storefront.
[0075] In another alternative embodiment, customer purchase
requests are not processed immediately. Instead, purchase requests
from many different consumers may be aggregated by the payment
processing organization and presented to suppliers and issuers as
an aggregated request.
[0076] Another alternative embodiment is an automated or
standing-request embodiment. In this embodiment, a consumer may
make a purchase request that is stored with the payment processing
organization. The payment processing organization will periodically
solicit offers for goods, services, and financing from suppliers
and issuers. Whenever a supplier or issuer makes an offer that
qualifies under the standing-request, the consumer will accept the
offer. This process can occur a pre-determined number of time or
indefinitely.
[0077] In yet another embodiment, in addition to searching for
items/service and financing, the payment processing organization
may also search for and present other relevant items for the
transaction. For example, in one embodiment, the payment processing
organization may search for coupons that are relevant for the items
or financing used by the consumer.
VII. Computer Apparatuses
[0078] FIG. 6 shows a block diagram of subsystems that may be
present in computer apparatuses that can be used according to
various embodiments.
[0079] The various participants and elements in the previously
described Figures may operate using one or more computer
apparatuses (e.g., the previously described communication device
110, or a server computer in the payment processing network 130) to
facilitate the functions described herein. Any of the elements in
the Figures may use any suitable number of subsystems to facilitate
the functions described herein. Examples of such subsystems or
components are shown in a FIG. 6. The subsystems shown in FIG. 6
are interconnected via a system bus 775. Additional subsystems such
as a printer 774, keyboard 778, fixed disk 779 (or other memory
comprising computer readable media), monitor 776, which is coupled
to display adapter 782, and others are shown. Peripherals and
input/output (I/O) devices, which couple to I/O controller 771, can
be connected to the computer system by any number of means known in
the art, such as serial port 777. For example, serial port 777 or
external interface 781 can be used to connect the computer
apparatus to a wide area network such as the Internet, a mouse
input device, or a scanner. The interconnection via system bus
allows the central processor 773 to communicate with each subsystem
and to control the execution of instructions from system memory 772
or the fixed disk 779, as well as the exchange of information
between subsystems. The system memory 772 and/or the fixed disk 779
may embody a computer readable medium. Any of these elements may be
present in the previously described features. For example, the
previously described directory server and access control server may
have one or more of these components shown in FIG. 6.
[0080] A computer readable medium according to an embodiment may
comprise code for performing any of the functions described above.
For example, the previously described servers run by a payment
processing organization may comprise a computer readable medium
comprising: a) code for receiving a purchase request message over a
network; and b) code for sending messages to suppliers and issuers.
The server may also have a processor coupled to the computer
readable medium, where the processor executes instructions embodied
by computer code on the computer readable medium.
[0081] It should be understood that the present invention as
described above can be implemented in the form of control logic
using computer software in a modular or integrated manner. Based on
the disclosure and teachings provided herein, a person of ordinary
skill in the art will know and appreciate other ways and/or methods
to implement the present invention using hardware and a combination
of hardware and software.
[0082] Any of the software components or functions described in
this application, may be implemented as software code to be
executed by a processor using any suitable computer language such
as, for example, Java, C++ or Perl using, for example, conventional
or object-oriented techniques. The software code may be stored as a
series of instructions, or commands on a computer readable medium,
such as a random access memory (RAM), a read only memory (ROM), a
magnetic medium such as a hard-drive or a floppy disk, or an
optical medium such as a CD-ROM. Any such computer readable medium
may reside on or within a single computational apparatus, and may
be present on or within different computational apparatuses within
a system or network.
[0083] A recitation of "a", "an" or "the" is intended to mean "one
or more" unless specifically indicated to the contrary.
[0084] The above description is illustrative and is not
restrictive. Many variations of the disclosure will become apparent
to those skilled in the art upon review of the disclosure. The
scope of the disclosure should, therefore, be determined not with
reference to the above description, but instead should be
determined with reference to the pending claims along with their
full scope or equivalents.
[0085] One or more features from any embodiment may be combined
with one or more features of any other embodiment without departing
from the scope of the disclosure.
[0086] All patents, patent applications, publications, and
descriptions mentioned above are herein incorporated by reference
in their entirety for all purposes. None is admitted to be prior
art.
* * * * *