CA2267042A1 - Method and system for local electronic bill presentment and payment ebpp - Google Patents
Method and system for local electronic bill presentment and payment ebpp Download PDFInfo
- Publication number
- CA2267042A1 CA2267042A1 CA 2267042 CA2267042A CA2267042A1 CA 2267042 A1 CA2267042 A1 CA 2267042A1 CA 2267042 CA2267042 CA 2267042 CA 2267042 A CA2267042 A CA 2267042A CA 2267042 A1 CA2267042 A1 CA 2267042A1
- Authority
- CA
- Canada
- Prior art keywords
- echeck
- payment
- biller
- customer
- ebpp
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/14—Payment architectures specially adapted for billing systems
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Finance (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Description
Title Method and System for Local Electronic Bill Presentment and Payment EBPP
Background of the Invention Electronic Bill Presentment and Payment ("EBPP") is being used by billers such as utility companies and telephone companies to deliver billing information to their customers.
Traditionally this information has been delivered as a printed paper document through postal mail. With EBPP the bill information is converted to an electronic format such as HTML
("Hypertext Markup Language") (or any other suitable format), and posted on a web site (or other suitable access point) for the customer to view using the Internet (or other suitable electronic communication media). The customer can electronically make the payment while at the bill presentment web site. Two models are being used today, consolidator and direct. In the consolidator model, a number of billers send their bills electronically to the host consolidator providing a centralized presentment of bills for the consumer. In the direct model, billers host their own bill presentment web site and customers must visit each of their billers web sites.
Problem 1 Electronic Bill Presentment and Payment EBPP models proposed to date are based on the Consolidator Biller model and the Direct Biller models. Both models require the biller's customer to log onto the bill presentment web sites which is hosted by the consolidator in the consolidator model, or the biller in the direct model. There are several problems associated with both of these models.
Because the bills are processed and centrally consolidated by the consolidator, the consolidator is viewed as providing a service to the customer. In addition to other possible problems, there are the following problems with the consolidator model:
1. Loss of biller and customer direct relationship
Background of the Invention Electronic Bill Presentment and Payment ("EBPP") is being used by billers such as utility companies and telephone companies to deliver billing information to their customers.
Traditionally this information has been delivered as a printed paper document through postal mail. With EBPP the bill information is converted to an electronic format such as HTML
("Hypertext Markup Language") (or any other suitable format), and posted on a web site (or other suitable access point) for the customer to view using the Internet (or other suitable electronic communication media). The customer can electronically make the payment while at the bill presentment web site. Two models are being used today, consolidator and direct. In the consolidator model, a number of billers send their bills electronically to the host consolidator providing a centralized presentment of bills for the consumer. In the direct model, billers host their own bill presentment web site and customers must visit each of their billers web sites.
Problem 1 Electronic Bill Presentment and Payment EBPP models proposed to date are based on the Consolidator Biller model and the Direct Biller models. Both models require the biller's customer to log onto the bill presentment web sites which is hosted by the consolidator in the consolidator model, or the biller in the direct model. There are several problems associated with both of these models.
Because the bills are processed and centrally consolidated by the consolidator, the consolidator is viewed as providing a service to the customer. In addition to other possible problems, there are the following problems with the consolidator model:
1. Loss of biller and customer direct relationship
2. Potential of cross selling to the biller's customer through the consolidator by other billers
3. Intermediary costs paid to the consolidator for hosting the web site
4. Loss of privacy for customer and the biller. The consolidator has the potential to monitor transactions and collect data.
5. Payment may need to be handled by an intermediary payment processor resulting in more costs.
In addition to other possible problems, there are the following problems with the direct biller model:
1. Difficulty for a customer to manage many direct biller hosted web sites 2. Payment may need to be handled by an intermediary payment processor It is an object ofthe invention to provide a novel method and system for Electronic Bill Presentment and Payment which obviates or mitigates at least one of the disadvantages of the prior art.
Solution to Problem 1 In the present invention for EBPP, based on existing electronic check or "echeck" technology, bills are locally consolidated by the customer rather then being centrally consolidated by the consolidator. One type of electronic check is discussed in U.S. Patent 5,677,955. As an example of local consolidation, the billers send bills directly to the customer over Internet email in the same flow as paper bills are now sent from billers to customers. Local consolidation provides the customer with the benefit of the automated consolidation but unlike existing EBPP systems it also preserves the benefit of the direct and private relationship between the biller and customer, as is now found in paper bills mailed to the customer. Accordingly, Billers do not need to hand their customers to others.
Furthermore, because there is no need for an intermediary, the costs can be reduced. Payments can be made using echeck eliminating the need for a payment processor.
Upon receiving and reviewing the ebill, the customer emails an echeck to the biller directly. In a particular aspect of the invention, electronic document processing allows for the automated creation of the echeck from the ebill ("electronic bill"). In addition, local consolidation of EBPP, which can also be called private EBPP, can enable mobile eBilling using PDA's ("Personal Digital Assistants" such as a Palm Pilot III equipped with a pager card or a RIM
Pager) that access Internet email.
Problem 2 The electronic cheque or "echeck" as a payment mechanism will require an echeck payers bank to be echeck enabled in order for echeck issuers and echeck depositors to use echecks. This lack of echeck infrastructure could inhibit the quick adoption of echeck for use in electronic bill presentment and electronic payment (EBPP) where a biller has many customers who may bank with many different banks who may not even be aware of echeck.
Solution to problem 2 For private EBPP, electronic check conversion of the echeck to an ACH
("Automated Clearing House") funds transfer payment, by the biller, would allow all customers of the biller to pay their bill with an echeck, regardless of their bank's ability to process echecks.
(Additional information regarding prior art methods of converting paper checks to ACH can be found at http://www.nacha.org/ecc/default.htm, an extract of which has been provided below.
"A check (being used as a source document), which is voided, is presented by the consumer and provides the MICR data necessary to format and route the electronic transaction to~the consumer' s account. The retail merchant obtains the consumer' s signature on an authorization and once the transaction is complete, the check is handed back to the consumer.
The ACH debit transaction is originated by the retail merchant or its processor (originator) and deposited with the collecting bank (ODFI). Each ACH debit transaction is sent by the ODFI through an ACH
Operator to the paying bank (RDFI). There is no storage requirement for the paper check, since it is handed back to the consumer.
However, since this transaction is governed by Regulation E, the retail merchant/originator is required to retain a copy of the signed authorization, and to produce a copy in the event of a dispute. The Originator will locate the signed authorization and other information as necessary to collect the returned ACH debit.
ACH returns are originated by the RDFI as necessary back through the ACH
Operator to the ODFI. The ODFI returns the ACH entry to the Originator. The ODFI or Originator can re-initiate in accordance with NACHA Rules." ) For those customers whose banks (payer bank) are not echeck enabled, the biller, biller's bank or other authorized agent for the biller could convert those echecks to an ACH
transaction. For those customers whose banks are echeck enabled, the check could be deposited in the biller's account as an echeck. As more banks become echeck enabled, the RDM echeck sorting technology would direct the legal echecks to now be echeck deposited.
The biller will deploy common echeck based electronic presentment and payment check issuing software to all of its customers regardless of the customers bank's (payer bank) ability to process an echeck.
Ebills would be emailed directly to the customer. The customer would pay their bills with an echeck payment. The echeck processing software at the biller (or at the bank) would sort the echecks by the customer's bank's ability to process echecks. The sort could be done by keeping a database of echeck enabled banks or by determining the origin of the customers digital certificate. Other sorts will occur to those of skill in the art and are within the scope of the invention. For example a biller or biller bank could issue the certificate.
If the sort determined that the customers bank could process echecks, (directly or through a third party) the biller would deposit the echeck.
If the sort determined that the customer's bank could not process echecks the biller could convert the echeck to an ACH payment that all banks can accept.
This solution would allow the immediate use of echeck for EBPP regardless of the infrastructure that exists for echecks.
If the customer's bank is echeck-enabled they may obtain their certificates directly from their bank. If the customer's bank is not echeck-enabled, the biller would deploy the certificates to the customer via a hardware token or as a software token via the Internet.
Innovations 1 The concept of EBPP where the biller(s) sends the bill directly to the customer and not by posting the bill on a web site hosted by the biller or by a consolidator.
2 The concept of consolidating the bills locally by the customer 3 The concept of interpreting a print stream, parsing it and converting the information to a machine processable electronic document and emailing it to a customer.
4 The concept of sorting an echeck by the payer bank's ability to process echecks The concept of sorting echecks by the origin of the certificates used to sign the echeck
In addition to other possible problems, there are the following problems with the direct biller model:
1. Difficulty for a customer to manage many direct biller hosted web sites 2. Payment may need to be handled by an intermediary payment processor It is an object ofthe invention to provide a novel method and system for Electronic Bill Presentment and Payment which obviates or mitigates at least one of the disadvantages of the prior art.
Solution to Problem 1 In the present invention for EBPP, based on existing electronic check or "echeck" technology, bills are locally consolidated by the customer rather then being centrally consolidated by the consolidator. One type of electronic check is discussed in U.S. Patent 5,677,955. As an example of local consolidation, the billers send bills directly to the customer over Internet email in the same flow as paper bills are now sent from billers to customers. Local consolidation provides the customer with the benefit of the automated consolidation but unlike existing EBPP systems it also preserves the benefit of the direct and private relationship between the biller and customer, as is now found in paper bills mailed to the customer. Accordingly, Billers do not need to hand their customers to others.
Furthermore, because there is no need for an intermediary, the costs can be reduced. Payments can be made using echeck eliminating the need for a payment processor.
Upon receiving and reviewing the ebill, the customer emails an echeck to the biller directly. In a particular aspect of the invention, electronic document processing allows for the automated creation of the echeck from the ebill ("electronic bill"). In addition, local consolidation of EBPP, which can also be called private EBPP, can enable mobile eBilling using PDA's ("Personal Digital Assistants" such as a Palm Pilot III equipped with a pager card or a RIM
Pager) that access Internet email.
Problem 2 The electronic cheque or "echeck" as a payment mechanism will require an echeck payers bank to be echeck enabled in order for echeck issuers and echeck depositors to use echecks. This lack of echeck infrastructure could inhibit the quick adoption of echeck for use in electronic bill presentment and electronic payment (EBPP) where a biller has many customers who may bank with many different banks who may not even be aware of echeck.
Solution to problem 2 For private EBPP, electronic check conversion of the echeck to an ACH
("Automated Clearing House") funds transfer payment, by the biller, would allow all customers of the biller to pay their bill with an echeck, regardless of their bank's ability to process echecks.
(Additional information regarding prior art methods of converting paper checks to ACH can be found at http://www.nacha.org/ecc/default.htm, an extract of which has been provided below.
"A check (being used as a source document), which is voided, is presented by the consumer and provides the MICR data necessary to format and route the electronic transaction to~the consumer' s account. The retail merchant obtains the consumer' s signature on an authorization and once the transaction is complete, the check is handed back to the consumer.
The ACH debit transaction is originated by the retail merchant or its processor (originator) and deposited with the collecting bank (ODFI). Each ACH debit transaction is sent by the ODFI through an ACH
Operator to the paying bank (RDFI). There is no storage requirement for the paper check, since it is handed back to the consumer.
However, since this transaction is governed by Regulation E, the retail merchant/originator is required to retain a copy of the signed authorization, and to produce a copy in the event of a dispute. The Originator will locate the signed authorization and other information as necessary to collect the returned ACH debit.
ACH returns are originated by the RDFI as necessary back through the ACH
Operator to the ODFI. The ODFI returns the ACH entry to the Originator. The ODFI or Originator can re-initiate in accordance with NACHA Rules." ) For those customers whose banks (payer bank) are not echeck enabled, the biller, biller's bank or other authorized agent for the biller could convert those echecks to an ACH
transaction. For those customers whose banks are echeck enabled, the check could be deposited in the biller's account as an echeck. As more banks become echeck enabled, the RDM echeck sorting technology would direct the legal echecks to now be echeck deposited.
The biller will deploy common echeck based electronic presentment and payment check issuing software to all of its customers regardless of the customers bank's (payer bank) ability to process an echeck.
Ebills would be emailed directly to the customer. The customer would pay their bills with an echeck payment. The echeck processing software at the biller (or at the bank) would sort the echecks by the customer's bank's ability to process echecks. The sort could be done by keeping a database of echeck enabled banks or by determining the origin of the customers digital certificate. Other sorts will occur to those of skill in the art and are within the scope of the invention. For example a biller or biller bank could issue the certificate.
If the sort determined that the customers bank could process echecks, (directly or through a third party) the biller would deposit the echeck.
If the sort determined that the customer's bank could not process echecks the biller could convert the echeck to an ACH payment that all banks can accept.
This solution would allow the immediate use of echeck for EBPP regardless of the infrastructure that exists for echecks.
If the customer's bank is echeck-enabled they may obtain their certificates directly from their bank. If the customer's bank is not echeck-enabled, the biller would deploy the certificates to the customer via a hardware token or as a software token via the Internet.
Innovations 1 The concept of EBPP where the biller(s) sends the bill directly to the customer and not by posting the bill on a web site hosted by the biller or by a consolidator.
2 The concept of consolidating the bills locally by the customer 3 The concept of interpreting a print stream, parsing it and converting the information to a machine processable electronic document and emailing it to a customer.
4 The concept of sorting an echeck by the payer bank's ability to process echecks The concept of sorting echecks by the origin of the certificates used to sign the echeck
6 Based on the echeck sort, the concept of converting the echeck to an electronic payment form, such as ACH, that will allow the transaction to complete, using the echeck in effect as a source document for obtaining payers bank account information and using the fact that it has been signed by the payer using a digital signature that has been accepted by both the biller and the payer as an authorization to do the ACH conversion.
7 Based on the echeck sort, the concept of converting the echeck to an electronic payment form, such as ACH, that will allow the transaction to complete, using the echeck in effect as a source document for obtaining payers bank account information and using the fact that it has been signed by the payer using a digital signature that has been accepted by both the biller and the payer and accompanied (attached) by an authorization document as referenced above in the quote from NACHA digitally signed by the Payer.
In an embodiment of the invention there is also provided a method to void the echeck which can be a necessary part of the conversion to ACH process. Here is an example of how this could be done:
a) Remove the signature block of the Payer from the eCheck and resave the eCheck so that the original eCheck is deleted. This copy of the eCheck will no longer validate.
b) Encrypt the signature block of the Payer using the public key of the Payee or the Public key of a third party such as the legal firm of the Payee. This allows the Payee to recover the signature block of the Payer (using the Payee's private key or have your legal firm recover it and provide a signed testament to that effect) reassemble the original eCheck and validate the signature. This ensures that the Payer can not repudiate the source document (the "voided" eCheck) used to support the conversion to ACH.
The Payee (or the Payee's legal firm or 3rd party as appropriate) will need to maintain in a secure location a history of Private Keys which expire from time to time.
c) Store the encrypted signature in such a way that it can be associated with the "voided" eCheck.
The attached Figures are examples of the present invention which reference certain embodiments.
Figure 1 is a flowchart of a method for local consolidation of electronic bill presentment to a customer and payment by the customer Figure 2 is a flowchart of a method for processing an electronic check received by a customer in payment of an electronic bill.
While only specific combinations of the various features and components of the present invention have been discussed herein, it will be apparent to those of skill in the art that desired sub-sets of the disclosed features and components and/or alternative combinations of these features and components can be utilized, as desired.
In an embodiment of the invention there is also provided a method to void the echeck which can be a necessary part of the conversion to ACH process. Here is an example of how this could be done:
a) Remove the signature block of the Payer from the eCheck and resave the eCheck so that the original eCheck is deleted. This copy of the eCheck will no longer validate.
b) Encrypt the signature block of the Payer using the public key of the Payee or the Public key of a third party such as the legal firm of the Payee. This allows the Payee to recover the signature block of the Payer (using the Payee's private key or have your legal firm recover it and provide a signed testament to that effect) reassemble the original eCheck and validate the signature. This ensures that the Payer can not repudiate the source document (the "voided" eCheck) used to support the conversion to ACH.
The Payee (or the Payee's legal firm or 3rd party as appropriate) will need to maintain in a secure location a history of Private Keys which expire from time to time.
c) Store the encrypted signature in such a way that it can be associated with the "voided" eCheck.
The attached Figures are examples of the present invention which reference certain embodiments.
Figure 1 is a flowchart of a method for local consolidation of electronic bill presentment to a customer and payment by the customer Figure 2 is a flowchart of a method for processing an electronic check received by a customer in payment of an electronic bill.
While only specific combinations of the various features and components of the present invention have been discussed herein, it will be apparent to those of skill in the art that desired sub-sets of the disclosed features and components and/or alternative combinations of these features and components can be utilized, as desired.
Claims
Priority Applications (3)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CA 2267042 CA2267042A1 (en) | 1999-03-26 | 1999-03-26 | Method and system for local electronic bill presentment and payment ebpp |
AU35459/00A AU3545900A (en) | 1999-03-26 | 2000-03-27 | Electronic invoice payment system |
PCT/CA2000/000317 WO2000058876A1 (en) | 1999-03-26 | 2000-03-27 | Electronic invoice payment system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CA 2267042 CA2267042A1 (en) | 1999-03-26 | 1999-03-26 | Method and system for local electronic bill presentment and payment ebpp |
Publications (1)
Publication Number | Publication Date |
---|---|
CA2267042A1 true CA2267042A1 (en) | 2000-09-26 |
Family
ID=4163410
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CA 2267042 Abandoned CA2267042A1 (en) | 1999-03-26 | 1999-03-26 | Method and system for local electronic bill presentment and payment ebpp |
Country Status (3)
Country | Link |
---|---|
AU (1) | AU3545900A (en) |
CA (1) | CA2267042A1 (en) |
WO (1) | WO2000058876A1 (en) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111080423A (en) * | 2019-11-04 | 2020-04-28 | 航天信息股份有限公司 | Safe tax control method and system based on white-box cryptographic algorithm |
Families Citing this family (53)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6363164B1 (en) | 1996-05-13 | 2002-03-26 | Cummins-Allison Corp. | Automated document processing system using full image scanning |
US8162125B1 (en) | 1996-05-29 | 2012-04-24 | Cummins-Allison Corp. | Apparatus and system for imaging currency bills and financial documents and method for using the same |
US7187795B2 (en) | 2001-09-27 | 2007-03-06 | Cummins-Allison Corp. | Document processing system using full image scanning |
US20050276458A1 (en) | 2004-05-25 | 2005-12-15 | Cummins-Allison Corp. | Automated document processing system and method using image scanning |
US8478020B1 (en) | 1996-11-27 | 2013-07-02 | Cummins-Allison Corp. | Apparatus and system for imaging currency bills and financial documents and method for using the same |
US8701857B2 (en) | 2000-02-11 | 2014-04-22 | Cummins-Allison Corp. | System and method for processing currency bills and tickets |
WO2001095203A1 (en) * | 2000-06-08 | 2001-12-13 | Kim Hong Il | A check/card for internet based commerce and a method for dealing the check/card |
US7647275B2 (en) | 2001-07-05 | 2010-01-12 | Cummins-Allison Corp. | Automated payment system and method |
US8428332B1 (en) | 2001-09-27 | 2013-04-23 | Cummins-Allison Corp. | Apparatus and system for imaging currency bills and financial documents and method for using the same |
US8437529B1 (en) | 2001-09-27 | 2013-05-07 | Cummins-Allison Corp. | Apparatus and system for imaging currency bills and financial documents and method for using the same |
US8944234B1 (en) | 2001-09-27 | 2015-02-03 | Cummins-Allison Corp. | Apparatus and system for imaging currency bills and financial documents and method for using the same |
US8437530B1 (en) | 2001-09-27 | 2013-05-07 | Cummins-Allison Corp. | Apparatus and system for imaging currency bills and financial documents and method for using the same |
US8433123B1 (en) | 2001-09-27 | 2013-04-30 | Cummins-Allison Corp. | Apparatus and system for imaging currency bills and financial documents and method for using the same |
US7822679B1 (en) * | 2001-10-29 | 2010-10-26 | Visa U.S.A. Inc. | Method and system for conducting a commercial transaction between a buyer and a seller |
DE10207932A1 (en) * | 2002-02-23 | 2003-09-25 | Bank Verlag Gmbh | Data processing system and method for electronic payment mediation |
US8171567B1 (en) | 2002-09-04 | 2012-05-01 | Tracer Detection Technology Corp. | Authentication method and system |
US8627939B1 (en) | 2002-09-25 | 2014-01-14 | Cummins-Allison Corp. | Apparatus and system for imaging currency bills and financial documents and method for using the same |
US8417017B1 (en) | 2007-03-09 | 2013-04-09 | Cummins-Allison Corp. | Apparatus and system for imaging currency bills and financial documents and method for using the same |
WO2008112132A1 (en) | 2007-03-09 | 2008-09-18 | Cummins-Allison Corp. | Document imaging and processing system |
US8538123B1 (en) | 2007-03-09 | 2013-09-17 | Cummins-Allison Corp. | Apparatus and system for imaging currency bills and financial documents and method for using the same |
AU2008287005A1 (en) | 2007-08-12 | 2009-02-19 | Elbizri, Samer | System and method of offsetting invoice obligations |
US20090070241A1 (en) * | 2007-09-07 | 2009-03-12 | Manohar Enterprises, Inc. | Bank balance funds check and negative balance controls for enterprise resource planning systems |
US8929640B1 (en) | 2009-04-15 | 2015-01-06 | Cummins-Allison Corp. | Apparatus and system for imaging currency bills and financial documents and method for using the same |
US8437532B1 (en) | 2009-04-15 | 2013-05-07 | Cummins-Allison Corp. | Apparatus and system for imaging currency bills and financial documents and method for using the same |
US8391583B1 (en) | 2009-04-15 | 2013-03-05 | Cummins-Allison Corp. | Apparatus and system for imaging currency bills and financial documents and method for using the same |
US9626664B2 (en) | 2012-03-07 | 2017-04-18 | Clearxchange, Llc | System and method for transferring funds |
US10318936B2 (en) | 2012-03-07 | 2019-06-11 | Early Warning Services, Llc | System and method for transferring funds |
US10395223B2 (en) | 2012-03-07 | 2019-08-27 | Early Warning Services, Llc | System and method for transferring funds |
US11593800B2 (en) | 2012-03-07 | 2023-02-28 | Early Warning Services, Llc | System and method for transferring funds |
US10970688B2 (en) | 2012-03-07 | 2021-04-06 | Early Warning Services, Llc | System and method for transferring funds |
US10395247B2 (en) | 2012-03-07 | 2019-08-27 | Early Warning Services, Llc | Systems and methods for facilitating a secure transaction at a non-financial institution system |
US10387858B2 (en) | 2013-02-07 | 2019-08-20 | Jpmorgan Chase Bank, N.A. | Integrated electronic cash flow management system and method |
US10282712B2 (en) | 2013-02-07 | 2019-05-07 | Jpmorgan Chase Bank, N.A. | Integrated electronic disbursement and cash flow management system and method |
US9141876B1 (en) | 2013-02-22 | 2015-09-22 | Cummins-Allison Corp. | Apparatus and system for processing currency bills and financial documents and method for using the same |
US10769606B2 (en) | 2015-03-23 | 2020-09-08 | Early Warning Services, Llc | Payment real-time funds availability |
US10878387B2 (en) | 2015-03-23 | 2020-12-29 | Early Warning Services, Llc | Real-time determination of funds availability for checks and ACH items |
US10839359B2 (en) | 2015-03-23 | 2020-11-17 | Early Warning Services, Llc | Payment real-time funds availability |
US10832246B2 (en) | 2015-03-23 | 2020-11-10 | Early Warning Services, Llc | Payment real-time funds availability |
US10748127B2 (en) | 2015-03-23 | 2020-08-18 | Early Warning Services, Llc | Payment real-time funds availability |
US10963856B2 (en) | 2015-07-21 | 2021-03-30 | Early Warning Services, Llc | Secure real-time transactions |
US11062290B2 (en) | 2015-07-21 | 2021-07-13 | Early Warning Services, Llc | Secure real-time transactions |
US10970695B2 (en) | 2015-07-21 | 2021-04-06 | Early Warning Services, Llc | Secure real-time transactions |
US11386410B2 (en) | 2015-07-21 | 2022-07-12 | Early Warning Services, Llc | Secure transactions with offline device |
US11157884B2 (en) | 2015-07-21 | 2021-10-26 | Early Warning Services, Llc | Secure transactions with offline device |
US11151523B2 (en) | 2015-07-21 | 2021-10-19 | Early Warning Services, Llc | Secure transactions with offline device |
US11037122B2 (en) | 2015-07-21 | 2021-06-15 | Early Warning Services, Llc | Secure real-time transactions |
US10956888B2 (en) | 2015-07-21 | 2021-03-23 | Early Warning Services, Llc | Secure real-time transactions |
US11151522B2 (en) | 2015-07-21 | 2021-10-19 | Early Warning Services, Llc | Secure transactions with offline device |
US11037121B2 (en) | 2015-07-21 | 2021-06-15 | Early Warning Services, Llc | Secure real-time transactions |
US10438175B2 (en) | 2015-07-21 | 2019-10-08 | Early Warning Services, Llc | Secure real-time payment transactions |
US20190147438A1 (en) * | 2016-05-04 | 2019-05-16 | Silvio Micali | Distributed transaction propagation and verification system |
US11144928B2 (en) | 2016-09-19 | 2021-10-12 | Early Warning Services, Llc | Authentication and fraud prevention in provisioning a mobile wallet |
CN111200529A (en) * | 2019-12-31 | 2020-05-26 | 航天信息股份有限公司 | System and method for improving access efficiency of gold tax disk group |
Family Cites Families (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6438527B1 (en) * | 1993-11-01 | 2002-08-20 | Visa International Service Association | Method and apparatus for paying bills electronically using machine readable information from an invoice |
US5677955A (en) | 1995-04-07 | 1997-10-14 | Financial Services Technology Consortium | Electronic funds transfer instruments |
US5832460A (en) * | 1995-06-02 | 1998-11-03 | International Business Machines Corporation | Method and system for bill presentation and payment reconciliation |
US5699528A (en) * | 1995-10-31 | 1997-12-16 | Mastercard International, Inc. | System and method for bill delivery and payment over a communications network |
US5884288A (en) * | 1996-07-01 | 1999-03-16 | Sun Microsystems, Inc. | Method and system for electronic bill payment |
US6044362A (en) * | 1997-09-08 | 2000-03-28 | Neely; R. Alan | Electronic invoicing and payment system |
-
1999
- 1999-03-26 CA CA 2267042 patent/CA2267042A1/en not_active Abandoned
-
2000
- 2000-03-27 AU AU35459/00A patent/AU3545900A/en not_active Abandoned
- 2000-03-27 WO PCT/CA2000/000317 patent/WO2000058876A1/en active Application Filing
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN111080423A (en) * | 2019-11-04 | 2020-04-28 | 航天信息股份有限公司 | Safe tax control method and system based on white-box cryptographic algorithm |
CN111080423B (en) * | 2019-11-04 | 2024-02-20 | 航天信息股份有限公司 | Safe tax control method and system based on white-box cryptographic algorithm |
Also Published As
Publication number | Publication date |
---|---|
WO2000058876A1 (en) | 2000-10-05 |
AU3545900A (en) | 2000-10-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CA2267042A1 (en) | Method and system for local electronic bill presentment and payment ebpp | |
US7051001B1 (en) | System and method for merchant function assumption of internet checking and savings account transactions | |
US20210042714A1 (en) | System and method for compositing items and authorizing transactions | |
US8600898B2 (en) | Electronic payment systems and methods utilizing digitally originated checks | |
Neuman et al. | Requirements for network payment: The netcheque perspective | |
US8924289B1 (en) | International banking system and method | |
AU2008212038B2 (en) | Worldwide cash vendor payment | |
JP4309852B2 (en) | Method and software application for automatically generating invoices | |
US20020016769A1 (en) | Method and system for on-line payments | |
US20140236817A1 (en) | Bar coded monetary transaction system and method | |
US20170061397A1 (en) | Electronic coin systems and methods utilizing coins digitally | |
US20060085337A1 (en) | Method and system for using payment cards as a payment option within an online bill payment and presentment solution | |
US20020138426A1 (en) | Concentration of electronic payments | |
AU2003204022A1 (en) | Business combined bill management system and method | |
Radecki et al. | Paying electronic bills electronically | |
Islam et al. | Analysis of blockchain-based Ripple and SWIFT | |
JP2006127453A (en) | Foreign remittance processing system and foreign remittance processing method using exchange | |
US20020083015A1 (en) | Settlement device and method | |
US7849006B2 (en) | Online staging of auction settlement transactions | |
US20190311334A1 (en) | Accelerated Check Processing | |
JP2002083125A (en) | Settlement management system, its method, and storage medium | |
JP2002163456A (en) | Billing service system and its method | |
TWM599957U (en) | Export banking centralized management system | |
WO2001008068A9 (en) | System, device, and method for coordinating and facilitating commercial transactions | |
KR20030084846A (en) | Bill/Checkbook Serving Management Method And Recoding Medium to Recode The Method |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
FZDE | Dead |