U.S. patent application number 09/879683 was filed with the patent office on 2001-12-20 for system, method and computer program product for allowing a carrier to act as a credit-approval entity for e-commerce transactions.
Invention is credited to Schweitzer, Limor.
Application Number | 20010054024 09/879683 |
Document ID | / |
Family ID | 22785062 |
Filed Date | 2001-12-20 |
United States Patent
Application |
20010054024 |
Kind Code |
A1 |
Schweitzer, Limor |
December 20, 2001 |
System, method and computer program product for allowing a carrier
to act as a credit-approval entity for e-commerce transactions
Abstract
A system, method and computer program product are provided for
paying for a transaction over the Internet. Initially, information
is received utilizing a network. Such information includes an
Internet Protocol (IP) address of a user and an amount of payment
due. An account is then identified using at least a portion of the
information, i.e. the IP address. Thereafter, payment is
administered for the payment due by billing against the account. In
a preferred embodiment, the present invention may be carried out by
a network service provider who provides the user with access to the
network.
Inventors: |
Schweitzer, Limor; (Santa
Clara, CA) |
Correspondence
Address: |
SILICON VALLEY INTELLECTUAL PROPERTY GROUP
P.O. BOX 721120
SAN JOSE
CA
95112
US
|
Family ID: |
22785062 |
Appl. No.: |
09/879683 |
Filed: |
June 11, 2001 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
60210966 |
Jun 12, 2000 |
|
|
|
Current U.S.
Class: |
705/40 |
Current CPC
Class: |
H04W 4/24 20130101; G06Q
20/02 20130101; G06Q 20/14 20130101; G06Q 20/325 20130101; H04L
69/16 20130101; H04W 48/16 20130101; H04M 15/44 20130101; G06Q
30/04 20130101; H04M 15/68 20130101; H04W 80/00 20130101; H04M
15/43 20130101; H04M 2215/0104 20130101; H04M 2215/0164 20130101;
H04M 2215/0172 20130101; H04L 9/40 20220501; H04M 15/00 20130101;
H04L 67/306 20130101; H04L 69/329 20130101; G06Q 20/16 20130101;
G06Q 20/102 20130101; G06Q 30/06 20130101; H04L 61/35 20130101;
G06Q 20/04 20130101; H04M 15/41 20130101; H04M 2215/2033 20130101;
H04M 15/53 20130101; H04M 15/55 20130101; H04L 12/1485 20130101;
H04M 15/52 20130101; H04M 2215/22 20130101; G06Q 20/12 20130101;
H04M 2215/32 20130101; H04L 12/14 20130101; H04L 12/1403 20130101;
H04M 2215/0196 20130101; H04M 2215/44 20130101 |
Class at
Publication: |
705/40 |
International
Class: |
G06F 017/60 |
Claims
What is claimed is:
1. A method for paying for a transaction over the Internet,
comprising: (a) receiving information utilizing a network, wherein
the information includes an Internet Protocol (IP) address of a
user and an amount of payment due; (b) identifying an account using
at least a portion of the information; and (c) administering
payment for the payment due by billing against the account.
2. The method as recited in claim 1, wherein a site sends the
information in response to the user carrying out a transaction
using the site.
3. The method as recited in claim 1, wherein the information
further includes port numbers.
4. The method as recited in claim 1, wherein the steps are carried
out by a network service provider.
5. The method as recited in claim 2, and further comprising the
steps of identifying user data based on the received information,
and sending the user data to the site.
6. The method as recited in claim 5, wherein the user data includes
shipping information.
7. The method as recited in claim 5, and further comprising the
step of requesting permission from the user prior to sending the
user data to the site.
8. The method as recited in claim 1, and further comprising the
step of limiting the administration of payment based on a rule.
9. The method as recited in claim 2, and further comprising the
step of collecting a fee from the site.
10. The method as recited in claim 9, wherein the fee is a
percentage of the payment due.
11. The method as recited in claim 1, wherein the account is a
debit account.
12. The method as recited in claim 1, wherein the steps are carried
out by a financial institution offering credit with credit cards in
conjunction with a network service provider.
13. A computer program product for paying for a transaction over
the Internet, comprising: (a) computer code for receiving
information utilizing a network, wherein the information includes
an Internet Protocol (IP) address of a user and an amount of
payment due; (b) computer code for identifying an account using at
least a portion of the information; and (c) computer code for
administering payment for the payment due by billing against the
account.
14. The computer program product as recited in claim 13, wherein a
site sends the information in response to the user carrying out a
transaction using the site.
15. The computer program product as recited in claim 13, wherein
the information further includes port numbers.
16. The computer program product as recited in claim 13, wherein
the computer code is executed by a network service provider.
17. The computer program product as recited in claim 14, and
further comprising computer code for identifying user data based on
the received information, and sending the user data to the
site.
18. The computer program product as recited in claim 17, wherein
the user data includes shipping information.
19. The computer program product as recited in claim 17, and
further comprising computer code for requesting permission from the
user prior to sending the user data to the site.
20. The computer program product as recited in claim 13, and
further comprising computer code for limiting the administration of
payment based on a rule.
21. The computer program product as recited in claim 14, and
further comprising computer code for collecting a fee from the
site.
22. The computer program product as recited in claim 21, wherein
the fee is a percentage of the payment due.
23. The computer program product as recited in claim 13, wherein
the account is a debit account.
24. The computer program product as recited in claim 13, wherein
the computer code is executed by a financial institution offering
credit with credit cards in conjunction with a network service
provider.
25. A system for paying for a transaction over the Internet,
comprising: (a) logic for receiving information utilizing a
network, wherein the information includes an Internet Protocol (IP)
address of a user and an amount of payment due; (b) logic for
identifying an account using at least a portion of the information;
and (c) logic for administering payment for the payment due by
billing against the account.
26. A method for paying for a transaction over the Internet,
comprising: (a) providing a link to a site on a network where a
business transaction is occurring; (b) receiving information from
the site at a third party location during the transaction, wherein
the information includes an Internet Protocol (IP) address of a
user and an amount of payment due; (c) identifying an account using
at least a portion of the information; (d) identifying whether any
rules are associated with the account; (e) conditionally
administering payment for the payment due by billing against the
account in accordance with any identified rules; (f) identifying
shipping information based on the received information; (g) sending
the shipping information to the site; and (h) receiving
compensation from the site.
Description
RELATED APPLICATIONS
[0001] The present application claims the priority of a provisional
application filed Jun. 12, 2000 under serial No. 60/210,966, and
which is incorporated herein by reference in its entirety. The
present application is further related to a co-pending application
filed concurrently herewith under the title "SYSTEM, METHOD AND
COMPUTER PROGRAM PRODUCT FOR CHARGING FOR COMPETITIVE
IP-OVER-WIRELESS SERVICES" and docket number XACCTP004 and naming
Limor Schweitzer as inventor, and a co-pending application filed
concurrently herewith under the title "SYSTEM, METHOD AND COMPUTER
PROGRAM PRODUCT FOR PREPAID WIRELESS VOICE COMMUNICATION AND IP
SERVICES" and docket number XACCTP005 and naming Limor Schweitzer
as inventor, which are each incorporated herein by reference in
their entirety.
FIELD OF THE INVENTION
[0002] The present invention relates to e-commerce, and more
particularly to administering payment for e-commerce
transactions.
BACKGROUND OF THE INVENTION
[0003] Over the last several years, businesses have been attracted
to the rapidly growing number of personal computer users. More
specifically, these businesses have realized the potential customer
base of the so-called "on-line users." On-line service providers
such as America Online, CompuServe, and Prodigy have provided easy
access to computer networks such that a large captive audience of
on-line consumers has emerged.
[0004] In the business arena, a merchant can, with an Internet
address and a hypertext editor, develop a first hypertext document
called a "home page" (or "virtual storefront") which a user sees
when he enters the Web at the merchant's Web server. That home page
may provide descriptions of products and services through the use
of media such as graphic images, sound, and hypertext link choices.
The information allows the consumer to find the product or service
he desires to purchase. The result is an easily accessible system
for purchasing anything from a journal page and investor advice to
travel tickets and golf clubs.
[0005] Several techniques for creating cashless commercial
transactions exist for sales over networks such as the Internet.
The most common technique involves the use of credit cards where
credit is extended to a cardholder by a financial institution to
cover purchases from participating merchants. The financial
institution pays the merchant the purchase price less a service
charge fee and later bills the cardholder for the purchase price.
During use, the merchant gets credit approval from credit card
companies using weak customer identification. Further, the merchant
communicates over secured link with the credit card company and
provides customer identifiers including credit-card number,
customer name, expiration date, billing address, etc. Of course,
this information must be collected from the customer during each
transaction.
[0006] Another system that allows for purchases without the use of
cash is a debit system. One example of such a system is NetBill. In
such systems, a large server maintains accounts for both merchants
and consumers. These NetBill accounts are linked with conventional
financial institutions. When a consumer chooses to purchase goods
or services from a merchant, a NetBill transaction is commenced in
which the product or service is transferred, if possible, e.g., a
journal page, the consumer's account is debited, and the merchant's
account is credited. When necessary, funds in the consumer's
NetBill account can be replenished by electronic transfer from a
bank or by credit card. Also, funds in the merchant's NetBill
account are made available by depositing the funds in the
merchant's bank account. Similar to the credit system, the merchant
must communicate with the debit system and provide customer
identifiers including a debit account identifier, customer name,
billing address, etc. Again, this information must be collected
from the customer during each transaction.
[0007] By requiring the merchant to collect the above credit and/or
debit account information for each transaction, both the merchant
and the customer are inconvenienced in terms of time and costs.
There is therefore a need for an improved technique of
administering payments for transactions carried out over the
Internet.
DISCLOSURE OF THE INVENTION
[0008] A system, method and computer program product are provided
for paying for a transaction over the Internet. Initially,
information is received utilizing a network. Such information
includes an Internet Protocol (IP) address of a user and an amount
of payment due. An account is then identified using at least a
portion of the information, i.e. the IP address. Thereafter,
payment is administered for the payment due by billing against the
account. In a preferred embodiment, the present invention may be
carried out by a network service provider, or carrier, who is
capable of providing the user with access to the network.
[0009] In one embodiment of the present invention, the account may
take the form of a debit account. Further, a site may send the
information to the network service provider, or carrier in response
to the user carrying out a transaction using the site. As an
option, the information may further include port numbers which are
associated with applications facilitating the required
transactions.
[0010] In another embodiment of the present invention, user data
may be identified by the network service provider, or carrierbased
on the received information. Such user data may then be sent to the
site. Optionally, the user data may include shipping information.
Further, permission may be requested from the user prior to sending
the user data to the site.
[0011] As an option, the administration of payment may be limited
based on a rule agreed upon by the site, the network operator or
carrier, and the consumer. Further, the network service provider,
or carrier may collect a fee from the site. Such fee may take the
form of a percentage of the payment due.
[0012] In various embodiments, the foregoing techniques may be
carried out by a financial institution offering credit in
conjunction with a network service provider.
BRIEF DESCRIPTION OF THE DRAWINGS
[0013] FIG. 1 illustrates a method for paying for a transaction
over the Internet;
[0014] FIG. 2 illustrates an exemplary flow process associated with
the method of FIG. 1;
[0015] FIG. 3 illustrates yet another exemplary flow process
associated with the method of FIG. 1;
[0016] FIG. 4 shows an exemplary accounting system and the manner
in which it interfaces with a conventional General Packet Radio
Service (GPRS) system for collecting IP content usage information
and call description record information; and
[0017] FIG. 5 illustrates a diagram showing a flow of information
using the system of FIG. 4.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
[0018] FIG. 1 illustrates a method 100 for paying for a transaction
over the Internet. Initially, in operation 102, information is
received from an e-commerce site utilizing a network. In one
embodiment, the information includes an Internet Protocol (IP)
address of a user and an amount of payment due. As an option, the
information may further include port numbers, and/or any other
information that may help identify the user and/or an associated
transaction. For security purposes, the information may be received
over a secure link.
[0019] It should be noted that the information may be received from
a site in response to a user carrying out a transaction using the
site. For example, the user may indicate that he or she wishes to
purchase goods or services using the site. Thereafter, the site may
send the information for payment purposes. In the alternative, the
information may be received from the user or a combination of the
user and the site.
[0020] Upon receipt of the information, an account is identified in
operation 104 using at least a portion of the information, namely
the IP address and port numbers. This may be accomplished by
keeping a database that links IP address and port numbers to
corresponding accounts. Tables may be constructed when an account
is established by a user for this purpose. In one embodiment, the
account may be a debit, credit or any other type of desired account
adapted to transfer value for payment purposes. In the case of a
debit account, regulatory credit checks may be avoided.
[0021] Thereafter, in operation 106, payment is administered for
the payment due by billing against the account. This may be
accomplished by sending a check to the site on which the
transaction occurred, transferring money to an account owned by the
site, or by other value transfer mechanisms. In a preferred
embodiment, the present invention may be carried out by a network
service provider or, in other words, carrier, who provides the user
with access to the network.
[0022] In another embodiment, the present invention may be carried
out by a financial institution offering conventional credit through
credit cards in conjunction with a network service provider who
provides the user with access to the network. During each
transaction, the user may provide his/her credit card information
to the financial institution, which is then correlated with the
user account information stored with the network service provider.
This leads to strengthened user authentication that greatly reduces
fraud.
[0023] As an option, user data may be identified based on the
received information. Such user data may then be sent to the site
for various purposes. In one embodiment, the user data may include
shipping information that is included in the aforementioned tables.
By providing the site with such shipping information, goods may be
delivered without asking the user to enter any additional
information. Optionally, permission may be requested from the user
prior to sending the user data to the site. In other embodiments,
the user data may include any information relating to the user and
facilitates e-commerce.
[0024] In order to more effectively interface with the e-commerce
sites, a hierarchy of purchasable item categories may be
maintained. Further, each e-commerce site may be required to sign
an agreement to tag goods and services with a category identifier
so that pre-selection can apply. In other words, the owners of the
debit accounts can pre-select purchasable categories when the
account is set up. To this end, the administration of payment may
be limited based on a user-determined rule. In particular, parents
may be permitted to control how kids spend their money, and
corporations may limit the scope of travel expenses. It should be
noted, however, that the administering of payment may be limited by
any rule. For example, the payment may be simply limited by a
maximum purchase price, etc.
[0025] In order to generate revenue, a fee may be collected from
the site for each transaction. In one embodiment, such fee may take
the form of a percentage of the payment due.
[0026] FIG. 2 illustrates an exemplary flow process associated with
the method 100 of FIG. 1. As shown, three parties may be involved
including a user 200 communicating from a computer, an e-commerce
site 202 communicating from a site on the Internet which is
accessible to the user via a conventional network connection. It
should be noted that any type of protocol may be used to interface
with the e-commerce site 202 including, but not limited to
hypertext transfer protocol (HTTP), wireless application program
(WAP), or any other protocol allowing the user 200 to communicate
with the e-commerce site 202. Further included in the process is a
carrier 204 which has a relationship with the user 200. In
particular, the carrier, or network service provider, 204 maintains
an account for the user 200. In the present description, the
network service provider is defined as being capable of providing
the user with access to the network.
[0027] As shown in FIG. 2, the user 200 interfaces with the
e-commerce site 202 in order to browse goods and services and
identify the prices thereof. See operation 208. During this
operation, an IP address and port numbers are conveyed. It should
be noted that this may be accomplished manually or, more
preferably, automatically upon receipt of a message using Internet
Protocol. As is well known, the IP address and port numbers may be
automatically retrieved from such a message.
[0028] Next, the e-commerce site 202 may indicate a discount to be
received if various goods and services are purchased. Further, the
carrier 204 may be identified in operation 210. Once the price is
identified, the user 200 may indicate whether he or she wishes to
purchase the goods or services in operation 212.
[0029] In response to the user 200 asking to purchase the goods or
services, the e-commerce site 202 sends the IP address, port
numbers and price of the goods or services to the carrier 204. Note
operation 214. It should be noted that the price may already
reflect the discount set forth in operation 210. In response
thereto, the carrier 204 may provide a uniform resource locator
(URL) to which the user 200 must link, as indicated in operation
216. This link is then relayed to the user 200 from the e-commerce
site 202 in operation 218. Ideally, such is relayed inside a
secured carrier network.
[0030] The foregoing URL allows the user 200 to view a form that
gives permission to the carrier 204 to pay the e-commerce site 202
the price using the debit account established between the user 200
and the carrier 204. As an option, such permission may further
include providing the e-commerce site 202 a shipping address which
the carrier 204 obtained when the debit account was established, or
updated thereafter. See operation 220. It should be noted that the
permission may be granted by the user 200 to the carrier 204 by
simply clicking an icon or any other more or less sophisticated
procedure.
[0031] In response to the permission being granted in operation
220, the carrier 204 provides the e-commerce site 202 with a
confirmation number and the shipping address in operation 222. As
such, the e-commerce site 202 is capable of shipping any goods to
the user, or providing a receipt therefor. A confirmation is then
sent from the e-commerce site 202 to the user 200 in operation
224.
[0032] With continuing reference to FIG. 2, a fee may be charged to
the e-commerce site 202 by the carrier 204 in operation 226. As an
option, this may be a percentage of the payment due for the
services, and may be simply deducted from the amount due to the
e-commerce site 202. Finally, the e-commerce site 204 may ship any
purchased goods to the user 200 using the shipping information, as
indicated in operation 228.
[0033] It should be noted that security cannot be infringed because
the customer confirmation is given by the user while accessing a
site that is internal to carrier 204, possibly with an IP address
that cannot be accessed from outside the carrier's network. The URL
of the internal site may be "pushed" at the browser by the
e-commerce site 204 (who can not access that URL because it is on
the wrong side of a firewall).
[0034] FIG. 3 illustrates yet another exemplary flow process
associated with the method 100 of FIG. 1. As shown, three parties
may again be involved including a user 300 communicating from a
computer, an e-commerce site 302 communicating from a site on the
Internet which is accessible to the user via a conventional network
connection. Further included in the process is a carrier gateway
304 which has a relationship with the user 300 similar to as
before.
[0035] In the present description, a gateway is a network point
that acts as an entrance to another network. The Internet typically
consists of gateway nodes and core nodes, where gateway nodes
interface with host nodes that generally reside at user premises.
The computers of network users and the computers that serve content
(such as Web pages) are host nodes. The computers that control
traffic within a company's network or with a local Internet service
provider (ISP) are gateway nodes. In the network for an enterprise,
a computer server acting as a gateway node is often also acting as
a proxy server and a firewall server. Gateways also involve the use
of router and switch.
[0036] As shown in FIG. 3, the user 300 initially transmits a
request for prices on goods or services in operation 306. This
request is then received by the carrier gateway 304 which in turn
relays the request in operation 308. Such request may further
identify the carrier associated with the gateway 304.
[0037] In response thereto, the e-commerce site 302 sends an
indication of the price to the user 300 by way of the carrier
gateway 304. Note operation 310. This request is then relayed from
the carrier gateway 304 to the user 300. As shown, the price may be
modified in order to generate revenue for the carrier associated
with the carrier gateway 304. The user is then given the
opportunity to purchase the goods and services in operation 313
which is, in turn, relayed from the carrier gateway 304 to the
e-commerce site 302. See operation 314.
[0038] In addition to relaying the purchase request in operation
314, a user identifier and/or shipping information may also be
transmitted to the user e-commerce site 302 from the carrier
gateway 304, as indicated in operation 316. If such information is
sufficient, the e-commerce site 302 may indicate to the carrier
gateway 304 that the purchase is complete in operation 318. Such
message may then be relayed from the carrier gateway 304 to the
user 300 in operation 320.
[0039] With continuing reference to FIG. 3, the purchase price may
be charged to the user 300 by the carrier gateway 304 in operation
322. Next, such money is relayed to the e-commerce site 302 in
operation 324. As an option, the money given to the e-commerce site
302 may reflect a fee for the services provided by the carrier
gateway 304.
[0040] It should be noted that the carrier may include an IP
network, WAP network, or a combination thereof. While implementing
transactions carried out over an IP network is commonly known to
those of ordinary skill, using a WAP network carrier may require
integration with a wireless network.
[0041] FIG. 4 shows an exemplary accounting system 400 and the
manner in which it interfaces with a General Packet Radio Service
(GPRS) system 402 for collecting IP content usage information and
call description record information. By providing such an
interface, transactions involving a wireless network are
facilitated. As shown, the exemplary system 400 includes a
plurality of data gatherers 404 which are in turn a component of a
plurality of information source modules (ISMs). Such ISMs interface
with the Serving GPRS Support Node (SGSN) and Gateway GPRS Support
Node (GGSN) of the GPRS system 402 for receiving the call
description records (CDRs) therefrom.
[0042] This may be accomplished by receiving CDRs directly from the
SGSN and/or GGSN. Also, the present invention may support the Ga
protocol as described by European Telecommunications Standards
Institute (ETSI) specs, accepting all types of CDRs produced by
SGSN and GGSN. This provides mobility, short message service (SMS),
and quality of service (QoS). It should be noted, however, that the
accounting system 400 may interface the GPRS system by any desired
means.
[0043] In one embodiment, the call description record information
may include conventional CDRs or any other data structure that is
collected from the GPRS system, and is descriptive of calls that
take place thereover. Further, the call description record
information may be collected by the data gatherers 404 of the ISMs,
which interface the GPRS system 402. Note FIG. 4.
[0044] As an option, the system 400 may use the received CDRs to
map IP content events to ISMs, resulting in a new type of call
description records, XDRs. Such XDR's get fed into rating engines
and then to a standard content based billing module 406. For more
information on how one exemplary content based billing module 406
operates, reference may be made to PCT application WO9927556A2
entitled "NETWORK ACCOUNTING AND BILLING SYSTEM AND METHOD"
published Jun. 3, 1999, and which is incorporated herein by
reference in its entirety.
[0045] FIG. 5 shows a flow of information using the system 400 of
FIG. 4. As shown, a plurality of IP-enabled mobile communication
units 502 are provided which are adapted to connect to a base
station BSS 504 over a Global System for Mobile Communication (GSM)
506 or any other wireless network.
[0046] A packet tunnel 508 is then created from the handset through
a SGSN of the BSS 504 to a router 510 logically located in the
GGSN. From that router 510, the packets are outputted to the
operator's IP network 512. A LDAP Radius server 514 may be
provisioned so that whenever mobile communication units belonging
to these corporate customers "log-in" to the network, they will be
given an IP address.
[0047] The present embodiment may collect the accounting
information from the different parts of the network, correlating
GPRS info with IP content. As an option, this may be accomplished
in a manner set forth in a co-pending patent application filed
concurrently herewith under the title "SYSTEM, METHOD AND COMPUTER
PROGRAM PRODUCT FOR CHARGING FOR COMPETITIVE IP-OVER-WIRELESS
SERVICES" and docket number XACCTP004 and naming Limor Schweitzer
as inventor. Converged data records may then be sent to be rated
and then sent to a conventional debit account mechanism 516. For
more information on one possible implementation of a debit account
mechanism 516, reference may be made to a co-pending application
filed concurrently herewith under the title "SYSTEM, METHOD AND
COMPUTER PROGRAM PRODUCT FOR PREPAID WIRELESS VOICE COMMUNICATION
AND IP SERVICES" and docket number XACCTP005 and naming Limor
Schweitzer as inventor.
[0048] While various embodiments have been described above, it
should be understood that they have been presented by way of
example only, and not limitation. Thus, the breadth and scope of a
preferred embodiment should not be limited by any of the
above-described exemplary embodiments, but should be defined only
in accordance with the following claims and their equivalents.
* * * * *