US20080288376A1

US20080288376A1 - Centralized payment hub method and system

Info

Publication number: US20080288376A1
Application number: US12/109,318
Authority: US
Inventors: Behram Panthaki; Aaron Rudenstine; Jeremy Sokolic; Amir Sunderji; Sanjeev Dheer; Neil Platt; Demetris Papademetriou
Original assignee: CashEdge Inc
Current assignee: CashEdge Inc; Wells Fargo Capital Finance LLC
Priority date: 2007-04-27
Filing date: 2008-04-24
Publication date: 2008-11-20
Also published as: EP2153395A1; WO2008134543A1; US8874480B2; CA2689425A1; EP2153395A4; US20080288400A1; US20120245983A1

Abstract

Embodiments described herein include an electronic transaction service network (also referred to herein as a centralized electronic transaction (CET) service). In another embodiment, a financial management system hosts a “central payment hub” version of the CET service. The central payment hub is an industrial utility in that multiple financial institutions all participate in a central service that can be offered to their respective customers. All of the customers (both individuals and small businesses) of the various institutions come to one consolidated payment hub. For example a Bank of America invoice can come into the payment hub, and a Wells Fargo invoice can come into the payment hub. The payment hub is a shared utility across multiple financial institutions. The payment hub features a single registration at the payment hub across all of the participating financial institutions.

Description

RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Patent Application Ser. No. 60/926,619, filed Apr. 27, 2007. This application also claims the benefit of U.S. Provisional Patent Application Ser. No. 60/957,634, filed Aug. 23, 2007.
This application is related to U.S. patent application Ser. No. 11/879,818, filed Jul. 19, 2007.

TECHNICAL FIELD

The invention is in the field of electronic payment methods and systems, including electronic financial networks.

BACKGROUND

Currently there are systems and methods for facilitating online transactions. FIGS. 1 and 2 illustrate one current system 100 used to facilitate making payments for online purchases. There are two categories of payment services available in such traditional systems. One category includes person-to-person and person-to-merchant payment services. The other category includes direct-to-merchant payment services. In such traditional methods, a user must open an account 104 with the service, referred to in FIGS. 1 and 2 as “X” service, and the user must fund the account. The account 104 must be funded using an external financial source 102, such as a checking account, a credit card, etc. In addition, funds must be kept on deposit in the account 104 for transfer or disbursement. The funds are transferred to the account 104 by the user with no sharing of information, such as information regarding other user accounts, or user creditors, etc. Money in the account 104 can be used for any of account service 112 offered by “X” service. Funds from the account 104 are distributed to payees 106 when the user performs a transaction that allows use of the “X” service, including payments to individuals 106A and to online stores 106B. Payment services 108 for person-to-person payments, and payment services 110 for direct-to-merchant payments are shown. Examples of such traditional services include the PayPal™ service.
However, current systems and methods for facilitating online transactions have significant limitations. FIG. 2 illustrates various limitations of the “X” service. For example, settlement time 113 for payment from the external financial source 102 to the user account 104 can be 3 to 4 days using a DDA account. When funds are transferred from the account 104 to multiple destination accounts 105, an additional 3 to 4 days settlement time is incurred in transferring the funds from the destination accounts 105 to a main bank account 117. This creates a worst-case settlement time of up to 8 days, not including any delays caused by verification processes at any transfer point.
Another disadvantage of such current systems is that the user must fund and manage the account 104 with “X” service as a separate account and relationship distinct from any other payor or payee relationships.

BRIEF DESCRIPTION OF THE DRAWINGS

FIGS. 1 and 2 illustrate a prior art system used to facilitate making payments for online purchases.

FIG. 3 is a block diagram illustrating an embodiment of a centralized electronic transaction (CET) service, which provides improved settlement time over existing payment methods, according to an embodiment.

FIG. 4 is a block diagram further illustrating direct-to-merchant payment CET services and person-to-person payment CET services, according to an embodiment.

FIG. 5 is a block diagram illustrating biller-direct invoicing for offline merchants, according to an embodiment.

FIG. 6 is a block diagram illustrating an embodiment in which the CET service and network is used by the “unbanked” to conduct transactions, according to an embodiment.

FIG. 7 is a block diagram of a system including a financial management system providing a CET system, according to an embodiment.

FIG. 8 is a block diagram illustration the operation of a funds transfer module, according to an embodiment.

FIG. 9 is a flow chart illustrating a CET service process, according to an embodiment.

FIG. 10 is a flow chart illustrating a CET service process of registering a user, according to an embodiment.

FIG. 11 is a block diagram of a system including a financial management system that hosts a central payment hub, according to an embodiment.

DETAILED DESCRIPTION

Embodiments described herein include an electronic transaction service network (also referred to herein as a centralized electronic transaction (CET) service). According to an embodiment, a financial management system hosts multiple CET web sites on behalf of multiple merchants. All transactions through any CET web site are executed and managed by the financial management system. Merchants may customize their web sites to include a branded look and feel. The merchant web sites are part of a CET service for which customer can register. Registered customers can then view and pay invoices from any merchants having CET web sites, whether purchases were made online or offline. Customers specify preferences for the CET service including choosing existing customer accounts from which the financial management system is to pay invoices on behalf of the customer. This eliminates the need for the customer to open and fund a separate payment account as in traditional methods.
The financial management system handles all transactions and data storage on behalf of merchants. Embodiments leverage existing financial institution (FI) payor and merchant networks. This allows merchants who are not large enough to provide online payment through conventional systems to have convenient online invoicing and payment services to offer their customers. This also allows customers of the financial management system to easily pay many different merchants online using a customer's existing account (such as a checking account, savings account, or credit card). Embodiments do not require a user to create, fund and maintain a separate account for the purpose of payment services. In an embodiment, a user or customer registers with the transaction CET service. The user is not required to create, fund and maintain a separate account in order to user the CET service. The term “user” and “customer” will be used interchangeably herein.
According to various embodiments, individuals who are “unbanked” (e.g., individuals who have no access to checking accounts, credit cards or other convenient non-cash payment mechanisms) may register with the CET service, and transact with online and offline merchants and make online payments.
One possible implementation of the CET service is by a small business that is part of the CET service. The business can create an invoice and send the invoice out to the customer, by mail or electronically. The customer, who is registered with the CET service, can access the invoice electronically, and automatically pay that invoice, for example through the customer's bank account.
Accounts payable can also be managed using the CET service. For example, consider a business that maintains a running account with a particular vendor. The business does not receive an invoice from the vendor, but can login to the CET service, view the account balance, and electronically pay the balance from another financial account of the business. The financial information does not need to be shared between the two entities.
Another functionality according to an embodiment is payroll management. For example, the business can login to the CET service and view payroll information. For employees who are also registered with the CET service, the business can pay the employee electronically from the business's financial account at a financial institution to the employee's chosen account at a (probably, but not necessarily, different) financial institution.
One embodiment of the CET service includes a branded biller-direct site. In contrast to previous methods, in which a customer or user logs into an “X” service web site, a biller-direct web site exists for the merchant or business. The business has the ability to customize the look and feel of this web site, which may be branded by the merchant or co-branded with the CET service. In an embodiment, there is a direct link to the (branded or co-branded) CET service web site from the business web site. An invoice, an email or some other communication is sent from the business to the customer with an indication that the required payment can be made directly on the business's CET service web site (the link to the web site is provided). The link takes the customer to the branded web site. In an embodiment, the web site includes the icon of the business and a CET service icon.
Co-branding embodiments include cross-sell opportunities. For example the consumer logging on to view a merchant invoice can be provided with information regarding promotions and discounts of the merchant. In addition, a business logging on to view its account information can be provided with information regarding network services.
In various embodiments, the CET service can be accessed in a variety of ways. For example, the user can login to the CET service web site and view the account information available for the user. The account information available for the user includes information related to all of the businesses with which the user has accounts that are also registered with the CET service. When the user clicks on an invoice of a particular business, a detail window with the invoice information also displays the branding of the invoicing business, as well as any cross-sell messaging provided by the invoicing business. Alternatively, the user can login to a business web site and view the user's account information for that particular business (e.g., via a link as previously described).
Businesses participating in the CET service may access various information when logged into the CET service web site. For example, all accounts receivable information for those customers participating in the CET service is visible. In addition, accounts payable information is also visible for those vendors participating in the CET service. Thus, a consolidated view of accounts, both receivable and payable, is available to the business participant. In addition, businesses can also leverage the service to make point of sales payments associated with an online shopping cart.
Non-business users can perform various functions when logged into the CET service. For example, the user can view the invoices placed there by a business, the user can pay invoices directly using the CET service, and the user can view a consolidated statement that includes payment history. Users can also leverage the service to make point of sale payments associated with a merchant shopping cart.
According to an embodiment, even if invoices are received offline, a user may still use the CET service web site to pay directly because the merchant or business knows the user and is aware of the relationship and account status. The web site can be used to remit the payment directly to the merchant account.
An existing user bank account is used to fund transactions according to the CET service. This is in contrast to having to create, fund and maintain a separate “X” service account as in existing payment methods and systems.
According to embodiments, the CET service offers rewards and other loyalty programs to users for participation in the CET service (e.g., for registering and completing transactions using the CET service). The rewards can be redeemed for goods, services, discounts, etc. This is in contrast to existing payment methods and systems, which do not make rewards available.
One embodiment of the CET service is implemented by a single financial institution offering the service to their customer. For example, the financial institution offered customers to sign up for the CET service (which may be branded by the financial institution or co-branded with the financial management system hosting the CET service) on the financial institution web site. In such embodiments, the financial institution also offers business customers the opportunity to have biller-direct web sites as described above, rather than the financial institution offering businesses this capability. In this scenario, the financial institution is in charge of the relationship with the participating merchants.
In another embodiment, the financial management system hosts a “central payment hub” version of the CET service. The central payment hub is an industrial utility in that multiple financial institutions all participate in a central service that can be offered to their respective customers. All of the customers (both individuals and small businesses) of the various institutions come to one consolidated payment hub. For example a Bank of America invoice can come into the payment hub, and a Wells Fargo invoice can come into the payment hub. The payment hub is a shared utility across multiple financial institutions. The payment hub features a single registration at the payment hub across all of the participating financial institutions. In an embodiment, the payment hub appears to users (individuals and small businesses) as a single, neutrally branded payment center across all of the participating financial institutions. Therefore, there is a single registration required in order for users to participate through any participating financial institution's web site or participating small business's web site.
FIG. 3 is a block diagram illustrating an embodiment of a CET service 300, including improved settlement time over existing payment methods, according to an embodiment. There is a single relationship model with the CET service; a user does not have to maintain a relationship and financial account with a separate payment service entity. Instead, the user selects among multiple funding options 302 including existing user bank accounts and credit cards. This provides several advantages. Because the primary account 302 designated by the user acts as the transactional account for the ET service, expanded capabilities of the primary account 302 are seamlessly available. For example, multiple transaction types are executed dependent only on the various channels used by the bank account/financial institution. This includes multiple payment paradigms, such as 3-day settlement, next-day settlement, and instant settlement. The CET service executes transaction using the primary account 302 (financial instruments, including DDAs and credit cards (CCs)) as shown at 304, but the user financial information is never shared with anyone, including the merchant or person being paid. The ET service enables the primary account 302 to be used for person-to-person payments, direct-to-merchant payments (as shown at 306), and any other type of transaction the user has available through the primary account 302. The funds from the primary account 302 are deposited directly in the bank account 308 of the person or merchant being paid.
Aspects of the CET service 300 and advantages thereof as described herein are particularly useful for a large financial institution desiring to incorporate the CET service in it offerings. However embodiments are not so limited. Embodiments of the CET service may be tailored as a stand-alone application or as an application tailored to be presented as a service of a particular large or small entity.
Table 1 below lists some of the market opportunities in the area of both online payments and other areas, such as serving the unbanked.

	TABLE 1

	OPPORTUNITY	FEATURES

ONLINE	Serving Online Businesses	Transact using primary
PAYMENTS	Provide easy-to-use and holistic	DDA/Card
	electronic payment and merchant	Online Direct-to-
	acquiring services to retail	Merchant payments
	consumers and hobbyists with a	Online Person-to-
	special focus on online	Person payments
	merchants	Online invoicing and
		collection (ACH/Card)
		Consolidated
		Reporting
	Serving Offline Businesses	Online invoicing and
	Leveraging a large base of	collection (ACH/Card)
	customers built in an adjacent	Biller Direct for small
	business (Retail, Card, Merchant	merchants
	Services, etc.) to build a network	Consolidated
	of currently underserved offline	Reporting
	merchants and non profit	Remote Deposit
	organizations	Capture
		Call Center Payments
OTHER	Add on Capability Serving the	Direct-to-Merchant
	Unbanked Leveraging an	and Person-to-Person
	emerging brand and ATM/	payments via ATM/
	Branch Networks to target the	Banking Center
	Unbanked

Table 2 below describes lists some of the services offered to consumers (also referred to as users or customers herein) and to merchants according to various embodiments.

TABLE 2

CONSUMERS	MERCHANTS

Transact using primary DDA/CARD	Receive payments from Card and
Online Direct-to-Merchant payments	DDA without merchant acquiring
Online Person-to-Person payment	relationship
Consolidated Reporting across	Online invoicing and collection
multiple financial relationships	(ACH/Card)
(payments and requests for payment)	For offline merchants, establish
Privacy and security-Banking	biller direct website
information is not shared with	Manage accounts payable
merchants	Consolidated Reporting across
	multiple financial relationships
	(payables and receivables)
	Other banking service-Remote
	Deposit Capture sweeps, etc.

FIG. 4 is a block diagram further illustrating direct-to-merchant payment CET services and person-to-person payment CET services, according to an embodiment. In a direct-to-merchant scenario, a consumer (also referred to as a customer or user) 402 accesses a merchant web site 404. As further described below, the merchant web site 404 is hosted by a financial management system that provides the CET service to many users and merchants, thus making it possible for small merchants or individual payees or billers to offer online payment. The CET service 300 actually receives user input from the web site 404 and executes transaction accordingly. For example, the CET service 300 performs online payment 406 as specified by the user 402 including DDA account payments at any financial institution, credit card payments, and short term loans.
In a person-to-person scenario, a user (also referred to as a customer or user) 408 accesses a DDA, for example through the web site of the financial institution 409 at which the DDA resides. The CET service 300 actually receives user input from the financial institution 409 and executes transactions accordingly. For example, the CET service 300 performs online payment as specified by the user 408 to one or more DDAs at another (payee) financial institution 410.
FIG. 5 is a block diagram illustrating biller-direct invoicing for offline merchants, according to an embodiment. A small business 502 communicates via a network (such as the Internet, a wide area network (WAN), etc.) with the CET service 300. The CET service 300 generates invoices or statements according to previously specified preferences of the small business 502. A customer 508 receives the invoice via mail, in this case (the invoice could also be sent via email or another method). The customer 508 logs into either a central CET service web site presented by the financial management system that hosts the CET service, or a branded biller-direct web site. On either web site the customer 508 can set up payments, view paid and unpaid invoices, view payment history, and view outstanding balances. The customer 508 can schedule electronic payment of any invoices. The CET service executes transactions necessary to pay the invoice including depositing funds from an existing customer account directly into an account designated by the small business 502.
The online capability to pay invoices received offline provides convenience to the customer, reduces payables processing cost for the customer, and makes payment time shorter. For small businesses, this capability reduces the time-to-pay and days outstanding. The capability also allows small businesses to automatically reconcile receivables, and reduce receivables processing costs. For financial institutions, this capability can be offered as a value-added service to small businesses. Financial institutions can realize subscription and transaction fee revenue for providing the service.
FIG. 6 is a block diagram illustrating an embodiment in which the CET service and network is used by the “unbanked” to conduct transactions, according to an embodiment. The unbanked include individuals that have no way of making electronic payments. The unbanked must currently go to the U.S Post Office or Western Union and obtain a money order or moneygram in order to make payments. This is an opportunity for financial institutions to use their ATM/branch networks to allow these unbanked consumers to transact offline for goods and services provided online. In an example, a consumer 602 shops online at a merchant 604 and chooses to pay using a payment kiosk 606 which is via the CET service 300 or the bank itself (such as bank 608). The consumer 602 receives a unique confirmation number and instructions to pay. The merchant 604 receives the order and has the unique confirmation number. The consumer 602 goes to a payment kiosk at a banking center. The consumer 602 uses the confirmation number. Once the confirmation number is received it links the payment to the order. The consumer 602 can then select to deposit the funds directly. Some ATMs have the capability to scan cash in. The consumer 602 can also choose to walk up to a teller at the bank 608 and make the payment. The bank 608 receives the payment on behalf of the merchant 604. This service enables the unbanked population to make quicker payments. This also facilitates much faster delivery of the product to the consumer 602. There can be a transaction fee associated with the service.
The CET service 300 can thus be very valuable to the unbanked consumer who is enabled to make online purchases using cash or prepaid cards. Merchants also benefit because they can receive electronic payments from either banked or unbanked customers, expanding the customer base of the merchant. Financial institutions benefit by collecting transaction fee revenue. In addition, financial institutions have the ability to cross-sell other products or services to unbanked customers.
FIG. 7 is a block diagram of a system 700 including a financial management system 702, according to an embodiment. The system 700 includes various entities in communication with each other via a network 710, which is typically the Internet, but embodiments are not so limited. The financial management system 702 includes databases 706 that store financial institution information, user information, merchant information (including merchant preferences for individual biller-direct web sites, invoice information for merchants, etc.). The CET service 300 is included in the financial management system 702 and interoperates with a funds transfer module 704. The funds transfer module 704 communicates with multiple financial institutions to transfer funds as further described below. Servers 708 host multiple web sites and applications as described herein, including biller-direct web sites, at least one central CET service web site, invoicing applications, email applications, and setup applications, to name a few.
Merchants 712 communicate with the financial management system 702 as further described below for providing the CET service 300 to their customers, either through biller-direct web sites or through a central CET services web site. CET customer personal computers (PCs) 716 are an example of an interface between customers and the CET service 300. Customers may interface with the CET service 300 using other means, such as handheld devices, kiosks, etc. Funds sources 714 include financial institutions of all types that can transfer funds via the network 710 using established financial networks such as ATM, ACH, and debit networks.
FIG. 8 is a block diagram illustrating the operation of the funds transfer module 704, according to an embodiment. Financial institution # 2 is for the benefit of the funds transfer module 704, and in an embodiment is managed by a third party processor. In this instance “third party” infers that financial institution # 2 is separate and independent from financial institution # 1 and financial institution # 3. In order to transfer funds from a source account 802 (for example a customer account) to a destination account 806 (such as a merchant account), the funds transfer module 704 first executes a debit transaction with the source account 802. Then the funds from the first debit transaction are deposited in the central (or intermediate) account 804 in a first credit transaction.
The funds are then withdrawn from the central account 804 in a second debit transaction, and deposited in destination account 806 in a second credit transaction. Financial institutions # 1 and #2 have no knowledge of central account 804. This is in contrast to conventional electronic funds transfers in which the financial institution providing the funds and the financial institution receiving the funds must deal directly with each other and have particular information or data about each other in order to complete the transaction. As shown, the debit and credit transactions can be accomplished using any one of various existing networks, including but not limited to an ACH network, a debit network, and an ATM network.
FIG. 9 is a flow chart illustrating a CET service process 900, according to an embodiment. The financial management system (FMS) creates a hosted merchant biller-direct (MBD) web site at 902. At 904, the merchant customizes the MBD web site, including look and feel with branding indicia, specifying preferences such as merchant account(s), etc. A registered CET customer receives a merchant invoice with MBD web site information (usually a link to the MBD web site) as shown at 906. The registered CET customer goes to the MBD web site to view the merchant invoice at 908. At 910, the customer pays directly on MBD web site from a customer account (chosen previously per customer preferences). Payment is transferred directly from the customer account to the merchant account at 912.
FIG. 10 is a flow chart illustrating a CET service process 1000 of registering a user, according to an embodiment. A customer logs into the CET service at 1002. The customer designates one or more existing accounts from which to fund transactions at 1004. At 1006, the customer states various verification information, such as user names, passwords, personal identification information, etc. The customer states preferences at 1008, such as how the customer would like to receive invoices. All of the customer input is stored on the financial management system and not shared with other entities, including financial institutions, as shown at 1010. The registered customer can then access and use the CET service by clicking on a CET icon to pay any merchant that also uses the CET service at 1014. In addition, or alternatively, the registered user can then click on a branded or co-branded icon from a merchant site to pay the specific merchant at 1012.
FIG. 11 is a block diagram of a system 1100 including a financial management system 1102, according to an embodiment. The financial management system hosts a central payment hub 1101 that includes a CET service. The central payment hub 1101 is an industrial utility in that multiple financial institutions 1114 all participate in a central service that can be offered to their respective customers of the financial institutions. All of the customers (both individuals and small businesses) of the various financial institutions access one consolidated payment hub 1101. For example a Bank of America invoice can come into the payment hub 1101, and a Wells Fargo invoice can come into the payment hub 1101. The payment hub 1101 is a shared utility across multiple financial institutions 1114. The payment hub 1101 features a single registration at the payment hub across all of the participating financial institutions 1114. In an embodiment, the payment hub appears to users (individuals and small businesses) as a single, neutrally branded payment center across all of the participating financial institutions 1114. Therefore, there is a single registration required in order for users to participate through any participating financial institution's web site or participating small business's web site.
In an embodiment, all of the participating financial institutions 1114 offer the same neutrally branded or co-branded services to their customers and the services are provided by the central payment hub 1101. The value-added services this the payment hub allows the financial institutions 1114 to offer include originate point-to-point (P2P) payments, sending an invoicing and sending requests for payment of invoices, and merchant services/shopping cart payments on merchant web sites.
The payment hub 1101 features a common payment center/directory that enables customers to make payments on requests for payments/invoices, receive P2P payments, and make shopping cart payments on web sites for participating merchants' websites.
Participating banks 1114 can thus provide services to end users through the payment hub 1101, yet control the customer relationship. Participating banks 1114 underwrite and authorize service limits, and collects revenues from subscriptions to the services.
Services to individual customers (or consumers) include sending person-to-person email payments, and sending requests for payment.
Services to small businesses include sending employee and vendor payments to know third parties (where financial information shared between sender and receiver), sending email payments to anyone (where financial information is not shared between sender and receiver), sending invoices to collect payments, and sending shopping cart invoices to collect point-of-sale (POS) payments.
The receiver role in transactions is supported by the financial management system 1102 through the payment hub 1101. The receiver services include receiving invoices or requests for payments, and making payments on both. The receiver services further include receiving (collecting) email payments, adding and verifying financial accounts (e.g., DDA, credit card), and assigning account preferences for receiving payments or making payments on invoices or requests for payments. In various embodiments, the roles of receiver and sender are less clearly separated. The roles could be combined in that many typical receiver or sender functions are performed by the opposite party. The receiver role could be extended to subsume the sender role in some instances, for example.
The system 1100 includes various entities in communication with each other via a network 1110, which is typically the Internet, but embodiments are not so limited. The financial management system 1102 includes databases 1106 that store financial institution information, user information, and customer information (including invoice information, payment information, payment history information, verification information, etc.). The CET service/payment hub 1101 is included in the financial management system 1102 and interoperates with a funds transfer module 1104. The funds transfer module 1104 communicates with multiple financial institutions to transfer funds as further described below. Servers 1108 host multiple web sites and applications as described herein, including biller-direct web sites, financial institution web sites, at least one central payment hub service web site, invoicing applications, email applications, and setup applications, to name a few.
Merchants 1112 communicate with the financial institutions 1114 to initiate their participation in the payment hub 1101. Individual customers also communicate with the financial institutions 1114 to initiate their participation in the payment hub 1101. Customer personal computers (PCs) 1116 are an example of an interface between customers and the financial institutions 1114 and between the customers and the payment hub 1101 through the network 1110. Customers may interface with the network 1110 using other means, such as handheld devices, kiosks, etc.
Aspects of the systems and methods described herein may be implemented as functionality programmed into any of a variety of circuitry, including programmable logic devices (PLDs), such as field programmable gate arrays (FPGAs), programmable array logic (PAL) devices, electrically programmable logic and memory devices and standard cell-based devices, as well as application specific integrated circuits (ASICs). Some other possibilities for implementing aspects of the system include: microcontrollers with memory (such as electronically erasable programmable read only memory (EEPROM)), embedded microprocessors, firmware, software, etc. Furthermore, aspects of the system may be embodied in microprocessors having software-based circuit emulation, discrete logic (sequential and combinatorial), custom devices, fuzzy (neural) logic, quantum devices, and hybrids of any of the above device types. Of course the underlying device technologies may be provided in a variety of component types, e.g., metal-oxide semiconductor field-effect transistor (MOSFET) technologies like complementary metal-oxide semiconductor (CMOS), bipolar technologies like emitter-coupled logic (ECL), polymer technologies (e.g., silicon-conjugated polymer and metal-conjugated polymer-metal structures), mixed analog and digital, etc.
It should be noted that the various functions or processes disclosed herein may be described as data and/or instructions embodied in various computer-readable media, in terms of their behavioral, register transfer, logic component, transistor, layout geometries, and/or other characteristics. Computer-readable media in which such formatted data and/or instructions may be embodied include, but are not limited to, non-volatile storage media in various forms (e.g., optical, magnetic or semiconductor storage media) and carrier waves that may be used to transfer such formatted data and/or instructions through wireless, optical, or wired signaling media or any combination thereof. Examples of transfers of such formatted data and/or instructions by carrier waves include, but are not limited to, transfers (uploads, downloads, e-mail, etc.) over the Internet and/or other computer networks via one or more data transfer protocols (e.g., HTTP, FTP, SMTP, etc.). When received within a computer system via one or more computer-readable media, such data and/or instruction-based expressions of components and/or processes under the system described may be processed by a processing entity (e.g., one or more processors) within the computer system in conjunction with execution of one or more other computer programs.
Unless the context clearly requires otherwise, throughout the description and the claims, the words “comprise,” “comprising,” and the like are to be construed in an inclusive sense as opposed to an exclusive or exhaustive sense; that is to say, in a sense of “including, but not limited to.” Words using the singular or plural number also include the plural or singular number respectively. Additionally, the words “herein,” “hereunder,” “above,” “below,” and words of similar import refer to this application as a whole and not to any particular portions of this application. When the word “or” is used in reference to a list of two or more items, that word covers all of the following interpretations of the word: any of the items in the list, all of the items in the list and any combination of the items in the list.
The above description of illustrated embodiments of the systems and methods is not intended to be exhaustive or to limit the systems and methods to the precise forms disclosed. While specific embodiments of, and examples for, the systems components and methods are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the systems, components and methods, as those skilled in the relevant art will recognize. The teachings of the systems and methods provided herein can be applied to other processing systems and methods, not only for the systems and methods described above.
The elements and acts of the various embodiments described above can be combined to provide further embodiments. These and other changes can be made to the systems and methods in light of the above detailed description.
In general, in the following claims, the terms used should not be construed to limit the systems and methods to the specific embodiments disclosed in the specification and the claims, but should be construed to include all processing systems that operate under the claims. Accordingly, the systems and methods are not limited by the disclosure, but instead the scope of the systems and methods is to be determined entirely by the claims.
While certain aspects of the systems and methods are presented below in certain claim forms, the inventors contemplate the various aspects of the systems and methods in any number of claim forms. For example, while only one aspect of the systems and methods may be recited as embodied in machine-readable medium, other aspects may likewise be embodied in machine-readable medium. Accordingly, the inventors reserve the right to add additional claims after filing the application to pursue such additional claim forms for other aspects of the systems and methods.

Claims

1. A central electronic transaction method, comprising:

a financial management system hosting a central payment hub comprising a central electronic transaction (CET) service on behalf of a plurality of financial institutions, wherein the payment hub manages information of customers of the financial institution comprising individual customers and business customers, the information comprising requests for payment and payment options;

the financial management system receiving input from a customer, the input comprising,

customer information comprising an identification of at least one payment account, wherein the at least one payment account comprises an existing customer bank account;

a request to view customer invoices; and

and a request to pay a customer invoice; and

the financial management system executing a transaction in response to the received input, comprising transferring funds from the at least one payment account to a destination account.

2. The method of claim 1, wherein the requests for payment comprise invoices, statements, and electronic shopping carts.

3. The method of claim 1, further comprising the payment hub implementing online invoicing for a business customer through a web site identified with the business customer.

4. The method of claim 1, further comprising:

a business customer customizing a business customer web site to include a link to the payment hub for the use of customers of the business;

the business customer designating one or more accounts to receive funds transferred by the payment hub on behalf of customers of the business; and

the business customer viewing consolidated payment and invoicing information in response to a request to the payment hub.

5. The method of claim 1, wherein the customer information comprises verification information for the at least one payment account, including personal customer identification information and password information.

6. The method of claim 1, further comprising a customer of a business customer accessing the payment hub via a link in an email from the business customer.

7. The method of claim 1, further comprising the customer accessing the web site via a link on a web site of the payment hub.

8. The method of claim 1, further comprising receiving a customer registration that enables the customer to participate in the payment hub, comprising paying multiple payees via the payment hub, wherein paying multiple payees comprises viewing payee requests for payment on specific payee web cites and viewing multiple requests for payment from different payees on a payment hub web site, wherein payees comprise the business customers.

9. The method of claim 1, wherein executing the transaction comprises the payment hub:

executing a first debit transaction to withdraw funds from the at least one payment account at a first financial institution;

executing a first credit transaction to deposit the funds in an intermediate account at a second financial institution;

executing a second debit transaction to withdraw funds from the intermediate account; and

executing a second credit transaction to deposit the funds in the destination account at a third financial institution.

10. The method of claim 9, wherein the first debit transaction and the first credit transaction are executed using a first network.

11. The method of claim 9, wherein the second debit transaction and the second credit transaction are executed using a second network.

12. The method of claim 10, wherein the first network is chosen from a group comprising: an automatic clearing house (ACH) network; a debit network; an automated teller machine (ATM) network, and a proprietary network.

13. The method of claim 11, wherein the second network is chosen from a group comprising: an automatic clearing house (ACH) network; a debit network; and an automated teller machine (ATM) network.

14. A financial management system comprising:

a plurality of servers configurable to communicate with a plurality of financial institutions via at least one network; and

a plurality of storage devices, comprising,

databases that store customer information, wherein customers comprise customers of financial institutions including individual customers and business customers, and financial institution information; and

memory devices that store instructions that when executed, cause a central electronic transaction method to be executed, the method comprising,

a central payment hub hosted by the financial management system on behalf of the plurality of financial institutions managing information of the customers of the financial institution, the information comprising invoices, payment options, and payment histories;

the payment hub receiving input from a customer, the input comprising,

customer information comprising an identification of at least one source account, wherein the at least one source account comprises an existing customer bank account;

a request to view customer invoices on the web site; and

a request to pay a customer invoice; and

the payment hub executing a transaction in response to the received input, comprising transferring funds from the at least one source account to a predetermined destination account.

15. The financial management system of claim 14, wherein the financial management system hosts multiple web sites on behalf of multiple financial institutions.

16. The financial management system of claim 14, wherein the central electronic transaction method further comprises:

the business customer designating one or more destination accounts to receive funds transferred by the payment hub on behalf of customers of the business; and

17. The financial management system of claim 14, wherein the customer information comprises verification information for the at least one source account, including personal customer identification information and password information.

18. The financial management system of claim 14, wherein the central electronic transaction method further comprises an individual customer accessing the payment hub via a link in an email from the business customer.

19. The financial management system of claim 14, wherein the central electronic transaction method further comprises an individual customer of a business customer accessing the payment hub via a web site of one of the plurality of financial institutions.

20. The financial management system of claim 14, wherein the central electronic transaction method further comprises performing a customer registration that enables the customer to participate in the payment hub, comprising paying multiple payees via the payment hub, wherein paying multiple payees comprises viewing payee invoices on specific payee web cites and viewing multiple invoices from different payees on a payment hub web site, wherein a payee comprises an individual customer and a business customer.

21. The financial management system of claim 14, wherein executing the transaction comprises the financial management system:

executing a first debit transaction to withdraw funds from the at least one source account at a first financial institution;

executing a second credit transaction to deposit the funds in the predetermined destination account at a third financial institution.

22. The financial management system of claim 21, wherein the first debit transaction and the first credit transaction are executed using a first network.

23. The financial management system of claim 22 wherein the second debit transaction and the second credit transaction are executed using a second network.

24. The financial management system of claim 22, wherein the first network is chosen from a group comprising: an automatic clearing house (ACH) network; a debit network; and an automated teller machine (ATM) network.

25. The financial management system of claim 23, wherein the second network is chosen from a group comprising: an automatic clearing house (ACH) network; a debit network; and an automated teller machine (ATM) network.

26. A method for central electronic transaction management, the method comprising:

hosting a central payment hub for a plurality of financial institutions;

supporting web site links on web sites of the plurality of financial institutions which link to the central payment hub, wherein each of the financial institutions offers a plurality of central payment hub services to its customers, the services comprising invoicing and payment services;

receiving customer preferences comprising at least one designated destination account in which funds are to be deposited by the payment hub on behalf of a customer;

receiving registration input from a customer comprising customer personal information and customer source account information regarding an account from which funds are to be withdrawn to make payments on behalf of the customer;

receiving input from the customer comprising,

a request from the customer to view invoices;

a request to pay an invoice;

a request to view payment history; and

a request to send an invoice on behalf of the customer; and

executing a transaction in response to the request to pay comprising transferring funds from the customer source account to the at least one designated destination account.

27. The method of claim 26, wherein the customer comprises an individual customer of a financial institution and a business customer of the financial institution.

28. The method of claim 27, further comprising an individual customer of one of the plurality of financial institutions viewing invoices, paying invoices, and viewing payment history, wherein the invoices and the payment history are related to any business customer of any of the plurality of financial institutions by accessing the payment hub.