US20010054024A1

US20010054024A1 - System, method and computer program product for allowing a carrier to act as a credit-approval entity for e-commerce transactions

Info

Publication number: US20010054024A1
Application number: US09/879,683
Authority: US
Inventors: Limor Schweitzer
Original assignee: XACCT Technologies Ltd
Current assignee: Amdocs Development Ltd; Amdocs Israel Ltd
Priority date: 2000-06-12
Filing date: 2001-06-11
Publication date: 2001-12-20
Also published as: WO2001097185A2; US7092398B2; WO2001097554A2; AU2001272940A1; WO2001097186A2; WO2001097554A3; WO2001097186A3; US20010055291A1; AU2001269791A1; WO2001097185A3; AU2001268345A1

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.

Description

RELATED APPLICATIONS

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.[0001]

FIELD OF THE INVENTION

The present invention relates to e-commerce, and more particularly to administering payment for e-commerce transactions.

BACKGROUND OF THE INVENTION

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.

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.

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.

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.

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

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.

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.

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.

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.

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

FIG. 1 illustrates a method for paying for a transaction over the Internet; [0013]
FIG. 2 illustrates an exemplary flow process associated with the method of FIG. 1; [0014]
FIG. 3 illustrates yet another exemplary flow process associated with the method of FIG. 1; [0015]
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 [0016]
FIG. 5 illustrates a diagram showing a flow of information using the system of FIG. 4. [0017]

DESCRIPTION OF THE PREFERRED EMBODIMENTS

FIG. 1 illustrates a [0018] 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.
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. [0019]
Upon receipt of the information, an account is identified in [0020] 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.
Thereafter, in [0021] 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.
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. [0022]
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. [0023]
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. [0024]
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. [0025]
FIG. 2 illustrates an exemplary flow process associated with the [0026] 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.
As shown in FIG. 2, the [0027] 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.
Next, the [0028] 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.
In response to the [0029] 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.
The foregoing URL allows the [0030] 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.
In response to the permission being granted in [0031] 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.
With continuing reference to FIG. 2, a fee may be charged to the [0032] 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.
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 [0033] 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).
FIG. 3 illustrates yet another exemplary flow process associated with the [0034] 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.
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. [0035]
As shown in FIG. 3, the [0036] 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.
In response thereto, the [0037] 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.
In addition to relaying the purchase request in [0038] 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.
With continuing reference to FIG. 3, the purchase price may be charged to the [0039] 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.
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. [0040]
FIG. 4 shows an [0041] 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.
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 [0042] accounting system 400 may interface the GPRS system by any desired means.
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 [0043] data gatherers 404 of the ISMs, which interface the GPRS system 402. Note FIG. 4.
As an option, the [0044] 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.
FIG. 5 shows a flow of information using the [0045] 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.
A [0046] 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.
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 [0047] 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.
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. [0048]

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

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.