WO2001099017A1

WO2001099017A1 - System and method for vendor account validation in electronic commerce

Info

Publication number: WO2001099017A1
Application number: PCT/US2001/019926
Authority: WO
Inventors: Claude C. Bouffard; John P. Shannon
Original assignee: Gopin Inc
Priority date: 2000-06-22
Filing date: 2001-06-22
Publication date: 2001-12-27
Also published as: AU2001270066A1

Abstract

A transaction engine (108) for electronic commerce permits vendors (104a-104n) having an established base proprietary revolving or other accounts to allow their users to transact purchases against those accounts, even if those accounts are not by themselves Web-enabled. A transaction server (106) interrogates a vendor database (104a) containing consumers account information for secure authentication.

Description

SYSTEM AND METHOD FOR VENDOR ACCOUNT VALIDATION IN ELECTRONIC

COMMERCE

Field of the Invention

[0001] The invention relates to the field of electronic commerce, and more particularly to the seamless enablement of existing merchant accounts for Internet and other network transactions.

Background of the Invention

[0002] Increasing demand for Internet commerce has fueled a corresponding demand for different types of network payment and accounting systems. Many merchants or vendors operating in the Internet and other network commerce spaces have a need for online transaction recording and billing, whether those vendors have deployed electronic versions of their proprietary accounts or not. Thus, many large retailers and other vendors of goods and services resort to the capture of Web commerce by accepting established payment mechanisms, such as third party authorization against credit card accounts to permit the broadest base of customers the greatest purchase flexibility.

[0003] However, the use of third party payment systems involves several disadvantages to proprietary vendors. For one, the major credit network systems, such as Visa™, Mastercard™, Discover™, American Express™ and others frequently exact a transaction discount of between 2% and 5% or more in exchange for fulfillment of transactions using their service. In addition, vendors relying upon third party payment networks for fulfillment may be less able to implement rewards, affinity and other marketing programs with their customer base because of lack of data and other interoperability with those providers. [0004] In addition, if a vendor selects a given third party payment network, some portion of the vendor's potential customer base may not have access to revolving accounts on that or other network systems. More robust and universal payment options for electronic vendors are desirable.

Summary of the Invention

[0005] The invention overcoming these and other problems in the art relates to a system and method for vendor account validation in electronic commerce, in which an Internet or other network-based transaction architecture may incorporate access to proprietary payment account databases for transaction fulfillment, in a modular fashion. According to the invention, a transaction server may be configured to communicate with one or more proprietary account databases, such as a retail merchant's database, and relay transaction requests received over the internet or other network portals to validate against those vendor accounts.

[0006] Incorporation of this payment option is independent of the vendor's particular account implementation, and requires only that the vendor be able to provide an accessible interface to an account database for syndication according to the invention, which resource may be interrogated by telephony switch or other communications network. The breadth of a vendor's transaction space is increased, and customer flexibility is enhanced.

Brief Description of the Drawings

[0007] Figure 1 illustrates an overall architecture for transaction processing according to the invention.

[0008] Figure 2 illustrates a transaction processing event according to the invention. [0009] Figure 3 illustrates a flowchart of a transaction event according to the invention.

[0010] Figure 4 illustrates an overall architecture for transaction processing according to the invention in another regard.

Detailed Description of Preferred Embodiments

[0011] As illustrated in Figure 1, in the overall architecture of the invention a customer or consumer operating an Internet or other client 102 communicates via communication link 114 to one or more of a group of vendors 104a, 104b, ...104n (n arbitrary). The client 102 may be or include, for instance, a personal computer running the Microsoft Windows™ 95, 98, Millenium™, NT™, or 2000, Windows™CE™, PalmOS™, Unix, Linux, Solaris™, OS/2™, BeOS™, MacOS™ or other operating system or platform. The client 102 may also be or include a network-enabled appliance such as a WebTV™ unit, radio-enabled Palm™ Pilot or similar unit, a set-top box, a networkable game-playing console such as a Sony Playstation™ or Sega Dreamcast™, a browser-equipped cellular telephone, or other TCP/IP client or other device.

[0012] The communication link 114 to which client 102 is connected may be, include or interface to any one or more of, for instance, the Internet, an intranet, a PAN (Personal Area Network), a LAN (Local Area Network), a WAN (Wide Area Network) or a MAN (Metropolitan Area Network), a frame relay connection, an ATN (Advanced Intelligent Network) connection, a synchronous optical network (SONET) connection, a digital Tl, T3 or El line, a Digital Data Service (DDS) connection, DSL (Digital Subscriber Line) connection, an Ethernet connection , an ISDN (Integrated Services Digital Network) line, a dial-up port such as a N.90, N.34 or N.34bis analog model connection, a cable modem, an ATM (Asynchronous Transfer Mode) connection, or FDDI (Fiber Distributed Data Interface) or CDDI (Copper Distributed Data Interface) connections. The communications link 114 may furthermore be, include or interface to any one or more of a WAP (Wireless Application Protocol) link, a GPRS (General Packet Radio Service) link, a GSM (Global System for Mobile Communication) link, a CDMA (Code Division Multiple Access) or TDMA (Time Division Multiple Access) link such as a cellular phone channel, a GPS (Global Positioning System) link, CDPD (cellular digital packet data), a RIM (Research in Motion, Limited) duplex paging type device, a Bluetooth radio link, or an IEEE 802.11 -based radio frequency link. Communications link 114 may yet further be, include or interface to any one or more of an RS-232 serial connection, an IEEE-1394 (Firewire) connection, an IrDA (infrared) port, a SCSI (Small Computer Serial Interface) connection, a USB (Universal Serial Bus) connection or other wired or wireless, digital or analog interface or connection. Other illustrated communications links may include the same types of resources.

[0013] As illustrated in Figure 1, one or more of the group of vendors 104a, 014b...l04n may present Web or other network transaction pages and advertising, support and retail and other transactions and fulfillment according to the invention. The vendors may include, for example, retail organizations who may not have an Internet presence or infrastructure in place, but who may have existing proprietary revolving credit or other accounts distributed to and active with a customer base.

[0014] In the invention, a customer wishing to initiate a transaction clicks off their transaction information with one of the vendors 104a, 104b...l04n, along with a whole or partial indication of their identity or account held with that organization. Further examples of such organizations may include financial service providers, airline and travel companies and others. [0015] hi the invention, the authentication database 110 accessed by transaction server 106 may include records of proprietary accounts held by those particular merchants, supplied by cooperative arrangement with those businesses and other organizations. Authentication database 110 communicates via communications link 120 with telephony engine 108, for transaction authorization and fulfillment. The telephony engine 108 may be or include switching equipment such as the Nortel Networks DMS™ series of switching and management platforms.

[0016] The authentication database 110 in this regard may be, include or interface to the line information database (LIDB) data resources operating under the SS7 signaling standard and accessible in the public communications network, as understood by persons skilled in the art. The authentication database 110 may likewise be, include or interface to resources such as the ATT Corp. Billing Nalidation Application (BNA) or the U.S. West Business Nalidation Service (BNS), or others. Other database resources, for example, the Oracle™ relational database sold commercially by Oracle Corp., Informix™ DB2 (Database 2) or other data storage or query formats or platforms such as OLAP (On Line Analytical Processing), SQL (Standard Query Language), Microsoft Access™ or others may also be used, incorporated or accessed in the invention.

[0017] Once customer validation against the authentication database 110 is complete, a message maybe communicated via telephony engine 108 to a transaction server 106 authorizing the charging of the transaction to the customer's proprietary account. The transaction server 106 may be or include, for instance, a workstation running the Microsoft Windows™ NT™, Windows™ 2000, Unix, Linux , Xenix, IBM ATX, Hewlett-Packard UX, Novell Netware™, Sun Microsystems Solaris™, OS/2™, BeOS™, Mach, Apache, OpenStep™ or other operating system or platform. Fulfillment for the transaction may be by way of direct action on the vendor's proprietary account for reconciliation with monthly bills provided by that vendor. Alternatively, according to the invention transaction authorization may be relayed via the billing services 112 in place for the customer's local telephone or other communications facility. However, since the proprietary vendors utilizing the transaction engine of the invention do not rely upon third party billing agents, transaction discounts are not taken and friction in the electronic commerce for those vendors is decreased. Moreover, since there are fewer communications links required in the initiation, authorization and recording of a transaction, reliability is likewise increased.

[0018] Furthermore, since transaction authorization may be provided without the necessity of full customer identification, such as by password or other attributes without relaying full account fields, consumers using the transaction system of the invention may conduct their transactions anonymously. As illustrated in Figure 2, a consumer operating a client 102 may initiate a transaction with one or more of the vendors 104a, 104b...104n over the Internet or other network connection. The consumer may offer one or more attributes or identifiers in a secure exchange with the vendor.

[0019] The given vendor may then communicate the attributes supplied by the consumer to the authentication database 110 via transaction server 106. The transaction server 106 may validate the consumer's account against the database 110 using the attribute information, or query the user if further information if required. The vendor may then transmit a transaction acceptance message to the consumer at client 102, with or without receipt or other confirmation.

[0020] Transaction processing according to the invention will be described with reference to Figure 3. In step 302, processing begins. In step 304, the consumer at the client 102 inputs an ID or other identifying attribute or information, which may encrypted, h step 306, the vendor hosting the transaction receives the attribute and communicates that data to the transaction server 106.

[0021] The transaction server 106 in step 308 interrogates the proprietary authentication database 110 to validate the user against an active account. In step 310 the transaction server 106 replies to the vendor indicating confirmation of a valid account, along with transaction amounts or other information as appropriate.

[0022] In step 312, the consumer may be presented with a transaction completion message, or be queried for further information as necessary. In step 314, reconciliation of the individual vendor account within the authentication database 110 may take place. In step 316, billing action may be completed, for instance by recording the transaction against the consumer's individual account, or by transmission of billing information to the billing services 112 of the consumer's telephone or other provider.

[0023] An overall architecture according to the invention in another regard is illustrated in Figure 4, in which the interconnection of the transaction server 106, a telephony engine 108 such as the Nortel Networks DMS™ platform for metering, billing, or other associated services, the vendor transaction site or sites such as Web pages or other portals, the client and other aspects are shown. [0024] In general, according to the overall architecture in which the invention in one embodiment may operate, consumers may initiate and execute transactions over a dial-up, broadband or other internet or other network connections, which transactions may be monitored and mediated via transaction server 106, telephony engine 108 along with attendant database, communications and other resources. The messaging traffic between the consumer and the vendor, and between the vendor and the authentication resources, again may be of a partial, anonymous and/or secure nature.

[0025] This is at least in part because the invention does not demand the transmission of complete identity or account information, whether in the clear, encrypted or otherwise, at any one stage of the transaction process. Rather, a subset of selected attributes, fields or keywords may be queried between the consumer and the commercial vendor for the separate transmission to the party, company or other organization operating the transaction server 106, telephony engine 108 or authentication database 110, and only the party providing the authentication function necessarily records more complete information in order to carry out that task. As shown in that figure and described above, billing against the consumer's account, telephone bill or otherwise may be triggered by a validated authentication sequence whose details may never be communicated to the vendor. The vendor may consequently receive payment directly or indirectly from banks or other financial intermediaries separately after that process, with whom the consumer separately reconciles. Transaction privacy and flexibility for consumers are therefore enhanced.

[0026] The foregoing description of the system and method of the invention is illustrative, and variations in configuration and implementation will occur to persons skilled in the art. For instance, while the invention has been described with respect to consumers initiating transactions against their existing proprietary vendor accounts at Website of those organizations, it is possible according to the invention to permit other merchants to validate against accounts of other organizations in reciprocal or other arrangements.

[0027] Moreover, while the invention has been generally been described with respect to purchase transactions involving the debiting of the consumer's account, in another embodiment steps of the transaction processing may be executed in reverse manner to recharge, refund or otherwise credit the consumer's account.

[0028] Furthermore, while certain resources such as computing, data, communications or other resources illustrated as singular or standalone may be distributed, and one or more separate resources may be combined.

[0029] Likewise, companies, organizations or other parties operating or supervising different segments of the processing chain could be one in the same, so for example authentication entities could also own or operate the transaction engine or engines, or other resources. The scope of the invention is accordingly intended to be limited only by the following

claims.

Claims

What is claimed is:

1. A system for the management of electronic transactions, comprising:

a first interface to an authentication database including at least one proprietary account; and a second interface, communicating with the first interface, the second interface operative to communicate with at least one network-enabled transaction site to execute electronic transactions via the transaction site when validated against the authentication database.

2. The system of claim 1, wherein the at least one proprietary account is not independently network-enabled.

3. The system of claim 1, wherein the network-enabled transaction site comprises an Internet connection.

4. The system of claim 3, wherein the Internet connection comprises a Web site.

5. The system of claim 1, wherein the at least one proprietary account comprises at least one of a retail merchant account, a financial services account, and a travel account.

6. The system of claim 1, wherein the validation against the authentication database is performed using attribute data.

7. The system of claim 6, wherein the attribute data is a subset of information contained in the authentication database.

8. The system of claim 7, wherein the attribute data permits anonymous execution of the transaction against the at least one proprietary account.

9. The system of claim 1, further comprising a transaction server, communicating with the first interface and the second interface, the transaction server managing the execution of the transaction.

10. The system of claim 9, wherein the at least one proprietary account comprises a plurality of proprietary accounts.

11. A method for the management of electronic transactions, comprising: a) communicating with at least one network-enabled transaction site to execute an electronic transaction via the transaction site; and b) validating the transaction against an authentication database containing at least one proprietary account.

12. The method of claim 11, wherein the at least one proprietary account is not independently network-enabled.

13. The method of claim 12, wherein the network-enabled transaction site comprises an Internet connection.

14. The method of claim 13, wherein the network-enabled transaction site comprises a Web page.

15. The method of claim 14, wherein the at least one proprietary account comprises at least one of a retail merchant account, a financial services account and a travel account.

16. The method off claim 15, wherein the validation against the authentication database is performed using attribute data.

17. The method of claim 16, wherein the attribute data is a subset of information contained in the authentication database.

18. The method of claim 17, wherein the attribute data permits anonymous execution off the transaction.

19. The method of claim 11, further comprising a step (c) of managing the transaction via a transaction server.

20. The method of claim 11, wherein the at least one proprietary account comprises a plurality of proprietary accounts.