Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS20080288400 A1
Publication typeApplication
Application numberUS 12/109,309
Publication dateNov 20, 2008
Filing dateApr 24, 2008
Priority dateApr 27, 2007
Also published asCA2689425A1, EP2153395A1, EP2153395A4, US8874480, US20080288376, US20120245983, WO2008134543A1
Publication number109309, 12109309, US 2008/0288400 A1, US 2008/288400 A1, US 20080288400 A1, US 20080288400A1, US 2008288400 A1, US 2008288400A1, US-A1-20080288400, US-A1-2008288400, US2008/0288400A1, US2008/288400A1, US20080288400 A1, US20080288400A1, US2008288400 A1, US2008288400A1
InventorsBehram Panthaki, Aaron Rudenstine, Jeremy Sokolic, Amir Sunderji, Sanjeev Dheer, Neil Platt, Demetris Papademetriou
Original AssigneeCashedge, Inc.
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
Centralized Payment Method and System for Online and Offline Transactions
US 20080288400 A1
Abstract
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.
Images(11)
Previous page
Next page
Claims(25)
1. A central electronic transaction method, comprising:
a financial management system hosting a web site on behalf of a payee, wherein the web site displays information to customers of the payee, the information comprising invoices and payment options;
the financial management system receiving input from a customer of the payee, 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 on the web site; 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 predetermined payee account.
2. The method of claim 1, wherein the financial management system hosts multiple web sites on behalf of multiple payees.
3. The method of claim 1, further comprising:
the payee customizing the web site, including placing branding indicia on the web site; and
the payee designating one or more accounts to receive funds transferred by the financial management system on behalf of customers.
4. 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.
5. The method of claim 1, further comprising the customer accessing the web site via a link in an email from the payee.
6. The method of claim 1, further comprising the customer accessing the web site via a link on a web site of the financial management system.
7. The method of claim 1, further comprising receiving a customer registration in a central electronic transaction (CET) service that enables the customer to pay multiple payees via the CET service, wherein paying multiple payees comprises viewing payee invoices on specific payee web cites and viewing multiple invoices from different payees on a CET web site.
8. The method of claim 1, wherein executing the transaction comprises the financial management system:
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 predetermined payee account at a third financial institution.
9. The method of claim 8, wherein the first debit transaction and the first credit transaction are executed using a first network.
10. The method of claim 8, wherein the second debit transaction and the second credit transaction are executed using a second network.
11. The method of claim 9, 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.
12. The method of claim 10, 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.
13. 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, merchant information, 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 financial management system hosting a web site on behalf of a merchant, wherein the web site displays information to customers of the merchant, the information comprising invoices and payment options;
the financial management system receiving input from a customer of the merchant, 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 on the web site; 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 predetermined merchant account.
14. The financial management system of claim 13, wherein the financial management system hosts multiple web sites on behalf of multiple merchants.
15. The financial management system of claim 13, wherein the central electronic transaction method further comprises:
the merchant customizing the web site, including placing branding indicia on the web site; and
the merchant designating one or more accounts to receive funds transferred by the financial management system on behalf of customers.
16. The financial management system of claim 13, wherein the customer information comprises verification information for the at least one payment account, including personal customer identification information and password information.
17. The financial management system of claim 13, wherein the central electronic transaction method further comprises the customer accesses the web site via a link in an email from the merchant.
18. The financial management system of claim 13, wherein the central electronic transaction method further comprises the customer accesses the web site via a link on a web site of the financial management system.
19. The financial management system of claim 13, wherein the central electronic transaction method further comprises receiving a customer registration in a central electronic transaction (CET) service that enables the customer to pay multiple merchants via the CET service, wherein paying multiple merchants comprises viewing merchant invoices on specific merchant web cites and viewing multiple invoices from different merchants on a CET web site.
20. The financial management system of claim 13, wherein executing the transaction comprises the financial management system:
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 predetermined merchant account at a third financial institution.
21. The financial management system of claim 20, wherein the first debit transaction and the first credit transaction are executed using a first network.
22. The financial management system of claim 21 wherein the second debit transaction and the second credit transaction are executed using a second network.
23. The financial management system of claim 21, 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.
24. The financial management system of claim 22, 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.
25. A method for central electronic transaction management, the method comprising:
creating and hosting a merchant web site for each of multiple merchants;
receiving merchant customization information for a merchant web site comprising a look and feel for the merchant web site;
receiving merchant preferences comprising at least one designated merchant account in which funds are to be deposited by the financial management system on behalf of customers of the merchant in payment of merchant invoices;
receiving registration input from a customer comprising customer personal information and customer payment account information;
receiving input from the customer comprising,
a request from the customer to view merchant information comprising merchant invoices, wherein the request is entered by the customer from at least one of the merchant web site and a central financial management system web site; and
a request to pay a merchant invoice; and
executing a transaction in response to the request to pay comprising transferring funds from the customer payment account to one of the at least one designated merchant accounts.
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.

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.

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 programsto 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.

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 DDA/Card
holistic electronic payment Online Direct-to-Merchant
and merchant acquiring payments
services to retail consumers Online Person-to-Person
and hobbyists with a special payments
focus on online 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, merchants
Merchant Services, etc.) to Consolidated Reporting
build a network of currently Remote Deposit Capture
underserved offline merchants Call Center Payments
and non profit organizations
OTHER Add on Capability-Serving the Direct-to-Merchant and
Unbanked Person-to-Person payments
Leveraging an emerging brand via ATM/Banking Center
and ATM/Branch Networks to
target the 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.

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.

Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US8219473Nov 13, 2009Jul 10, 2012Byallaccounts, Inc.Financial portfolio management system and method
US8468090Nov 10, 2011Jun 18, 2013Hsbc Technologies Inc.Account opening computer system architecture and process for implementing same
US8473397Jun 5, 2012Jun 25, 2013Byallaccounts, Inc.Financial portfolio management system and method
US8589213Oct 19, 2011Nov 19, 2013Hsbc Technology & Services (Usa) Inc.Computer metrics system and process for implementing same
US8645248Oct 27, 2011Feb 4, 2014Hsbc Technology & Services (Usa) Inc.Integrated customer communications computer system and process for implementing same
US8666906Feb 17, 2012Mar 4, 2014Google Inc.Discrete verification of payment information
US20130073404 *Sep 18, 2011Mar 21, 2013Tyfone, Inc.Virtual open loop payment
US20130268337 *Aug 22, 2012Oct 10, 2013Anthony MorelloMethod and/or system for extending payment system architectures and/or order processing systems to assign merchant funded incentive options to customers performing a mobile remote check deposit capture (MRDC) routine from a smart mobile device to facilitate online commerce, online-to-offline (O2O) commerce and mobile commerce.
Classifications
U.S. Classification705/40
International ClassificationG06Q40/00, G06Q20/00
Cooperative ClassificationG06Q40/02, G06Q20/1085, G06Q20/10, G06Q20/102, G06Q40/12
European ClassificationG06Q40/02, G06Q40/10, G06Q20/102
Legal Events
DateCodeEventDescription
Apr 24, 2008ASAssignment
Owner name: CASHEDGE, INC., NEW YORK
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:PANTHAKI, BEHRAM;RUDENSTINE, AARON;SOKOLIC, JEREMY;AND OTHERS;REEL/FRAME:020853/0626;SIGNING DATES FROM 20080124 TO 20080317
Aug 5, 2008ASAssignment
Owner name: WELLS FARGO FOOTHILL, LLC, AS AGENT, MASSACHUSETTS
Free format text: SECURITY AGREEMENT;ASSIGNOR:CASHEDGE INC.;REEL/FRAME:021339/0153
Effective date: 20080731
Owner name: WELLS FARGO FOOTHILL, LLC, AS AGENT,MASSACHUSETTS
Free format text: SECURITY AGREEMENT;ASSIGNOR:CASHEDGE INC.;US-ASSIGNMENT DATABASE UPDATED:20100203;REEL/FRAME:21339/153
Free format text: SECURITY AGREEMENT;ASSIGNOR:CASHEDGE INC.;US-ASSIGNMENT DATABASE UPDATED:20100329;REEL/FRAME:21339/153
Owner name: WELLS FARGO FOOTHILL, LLC, AS AGENT,MASSACHUSETTS
Free format text: SECURITY AGREEMENT;ASSIGNOR:CASHEDGE INC.;US-ASSIGNMENT DATABASE UPDATED:20100203;REEL/FRAME:21339/153
Effective date: 20080731
Owner name: WELLS FARGO FOOTHILL, LLC, AS AGENT,MASSACHUSETTS
Free format text: SECURITY AGREEMENT;ASSIGNOR:CASHEDGE INC.;US-ASSIGNMENT DATABASE UPDATED:20100329;REEL/FRAME:21339/153
Effective date: 20080731
Owner name: WELLS FARGO FOOTHILL, LLC, AS AGENT,MASSACHUSETTS
Free format text: SECURITY AGREEMENT;ASSIGNOR:CASHEDGE INC.;REEL/FRAME:021339/0153
Effective date: 20080731
Feb 19, 2010ASAssignment
Free format text: SECURED PARTY NAME CHANGE;ASSIGNOR:WELLS FARGO FOOTHILL, LLC, AS AGENT;US-ASSIGNMENT DATABASE UPDATED:20100329;REEL/FRAME:23963/131
Free format text: SECURED PARTY NAME CHANGE;ASSIGNOR:WELLS FARGO FOOTHILL, LLC, AS AGENT;REEL/FRAME:023963/0131
Owner name: WELLS FARGO CAPITAL FINANCE, LLC, AS AGENT, MASSAC
Owner name: WELLS FARGO CAPITAL FINANCE, LLC, AS AGENT,MASSACH
Free format text: SECURED PARTY NAME CHANGE;ASSIGNOR:WELLS FARGO FOOTHILL, LLC, AS AGENT;US-ASSIGNMENT DATABASE UPDATED:20100219;REEL/FRAME:23963/131
Effective date: 20100115
Owner name: WELLS FARGO CAPITAL FINANCE, LLC, AS AGENT,MASSACH
Free format text: SECURED PARTY NAME CHANGE;ASSIGNOR:WELLS FARGO FOOTHILL, LLC, AS AGENT;US-ASSIGNMENT DATABASE UPDATED:20100329;REEL/FRAME:23963/131
Effective date: 20100115
Owner name: WELLS FARGO CAPITAL FINANCE, LLC, AS AGENT,MASSACH
Free format text: SECURED PARTY NAME CHANGE;ASSIGNOR:WELLS FARGO FOOTHILL, LLC, AS AGENT;REEL/FRAME:023963/0131
Effective date: 20100115
Owner name: WELLS FARGO CAPITAL FINANCE, LLC, AS AGENT, MASSAC
Free format text: SECURED PARTY NAME CHANGE;ASSIGNOR:WELLS FARGO FOOTHILL, LLC, AS AGENT;REEL/FRAME:023963/0131
Effective date: 20100115
Sep 14, 2011ASAssignment
Owner name: CASHEDGE, INC., NEW YORK
Free format text: RELEASE BY SECURED PARTY;ASSIGNOR:WELLS FARGO CAPITAL FINANCE, LLC, AS AGENT;REEL/FRAME:026902/0570
Effective date: 20110913