CA2306521A1 - Internet billing and payment system - Google Patents
Internet billing and payment system Download PDFInfo
- Publication number
- CA2306521A1 CA2306521A1 CA 2306521 CA2306521A CA2306521A1 CA 2306521 A1 CA2306521 A1 CA 2306521A1 CA 2306521 CA2306521 CA 2306521 CA 2306521 A CA2306521 A CA 2306521A CA 2306521 A1 CA2306521 A1 CA 2306521A1
- Authority
- CA
- Canada
- Prior art keywords
- customer
- invoice
- biller
- facilitator
- customers
- 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.)
- Withdrawn
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
- G06Q30/00—Commerce
- G06Q30/04—Billing or invoicing
-
- 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
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/2866—Architectures; Arrangements
- H04L67/30—Profiles
- H04L67/306—User profiles
Abstract
An open-architecture system and method of posting and paying invoices via the Internet permits multiple billers and multiple customers to use the system without requiring that customers be subscribers. A billing/payments facilitator establishes and maintains an interactive website that interacts with a database including selected particulars of individual billers and individual customers. For each invoice, the facilitator receives suitable billing data from a biller and posts the billing data on the website for access by the customer identified in the invoice. The facilitator notifies the customer that an invoice has been posted and provides the customer with a bill identification code. The facilitator displays the posted invoice to the customer upon receipt of such customer's bill identification code. The customer while on-line may authorize payment of the invoice by any approved electronic payment method.
The facilitator may deduct a transaction fee from the amount, the balance of which is passed on to the biller.
The facilitator may deduct a transaction fee from the amount, the balance of which is passed on to the biller.
Description
INTERNET BILLING AND PAYMENT SYSTEM
Field of the Invention This invention relates to an Internet billing and payment system to facilitate billings and payments using the Internet.
Background of the Invention A number of commercial transactions occur on the Internet.
Many Internet-based businesses operate by offering products or services for sale on the Internet, and by receiving payment from users or purchasers typically by way of submission by the user or purchaser of credit card information to the provider of goods or services, whereupon the credit card is debited and the goods and services are provided. Encryption and verification procedures have been developed to authenticate amounts billed and transferred, parties to transactions, and other particulars.
A number of Internet-based systems exist for consolidating bills and transmitting them to a billed customer. Typically, a postal, telecommunications or financial institution will gather together bills from various billing entities (billers), and allow Internet portal access to recognized customers to pay the total amount owing, or a portion thereof. Such payment is made to the bill consolidator service provider, who then distributes the amount received to the billers. In such arrangements, the individual billers (typically retailers) and the billed customers do not have a direct communications or payment link - the link with either exists only through the bill consolidator. Credit card companies may function in this manner. A representative prior patent directed to computerized billing and payment authorization systems is U.S. patent no. 5943656 granted to Crooks et al. on 24 August 1999. An alternative bill consolidation and payment aggregation and settlement system is described in U.S. Patent 5978780 granted to Watson on 2 November 1999.
The principal problem with bill consolidation processes and facilities of the foregoing sort is that only a limited number of subscribers may use the Internet-based system, and those subscribers do not have any direct communication or transaction links with the billing entities - rather, all transactions occur with the bill consolidator. This kind of billing consolidation procedure and facility cannot be used by either billing entities or billed entities to communicate with one another and arrange submission of invoices or payment of invoices directly to one another. Furthermore, the limited subscriber list of bill consolidators means that the bill consolidators' facilities cannot be easily used by the general public via the Internet.
Summary of the Invention According to the present invention, an open billing architecture is provided that enables any billing party to communicate an invoice or bill via the billing and payment facilitator's website to any customer (or at least to any customer having an Internet address), without requiring either party to be a subscriber to the billing service facilitator's system, and without restrictive funnelling of the various transactions through a bill consolidator or the like. The term "open architecture" is used to signify that the system is available to many users, be they billers or customers or both, without the need to record any users as subscribers to the system.
According to the invention, a centralized billing service facilitator operating a website (hereinafter "facilitator") permits a biller to present its bill or invoice as a discrete payable invoice directly to the billed customer. An invoice posting procedure according to the invention is described below.
The principal proviso is, of course, that the billed customer be reachable by a suitable communications link, which as a practical matter implies that the customer should have an Internet address.
The billed customer is alerted by an incoming e-mail message or equivalent notice (e.g. by pager) that the biller has sent the bill to the facilitator. The customer then may access the facilitator's website, review the invoice, and if the particulars are correct, arrange payment of the invoice via the facilitator.
The facilitator passes on the received amount to the biller, less a transaction fee unless some other arrangement is in place for compensating the facilitator. Payment may be effected by credit card, by debiting a bank account, or by any other means acceptable to the parties to the transaction.
By proceeding in this way, both the biller and the customer may avoid the delays and expense of using the postal service.
The system presumably would, of course, be subject to the usual security and privacy measures available to protect Internet sites and transactions; firewall protection against hackers and against "denial of service" bombardment would be established, as would any other form of Internet protection applicable to businesses operating on the Internet. Future security and privacy protection measures would presumably be applied as and when available and effective.
The entire system can optionally function without passwords and without subscribers, although purchasers may be offered a subscriber option that makes available such additional services as automatic access to a subscriber's designated bank account or the like, and billers may be offered a subscriber option that further facilitates various aspects of the processing of invoice posting and payments. Further, billers would be expected by direct agreement or by implication from the fact of using the facilitator's services to agree with the facilitator that the of the facilitator may extract a transaction fee; this condition of service may be implicit in the election by the biller to use the facilities of the website operated by the facilitator.
In greater particularity, the bill-posting and bill-payment process would work according to one aspect of the invention as follows, the posting procedure of course preceding the payment procedure:
A first on-line Internet invoice-posting session occurs between the biller and the facilitator;
a second on-line Internet invoice-review-and-payment session occurs between the customer (billed party) and the facilitator.
In both sessions, the facilitator functions in reactive mode; the initiating party for the first session is the biller and the initiating party for the second session is the customer. These sessions are premised on the maintenance by the billing service facilitator of a database that itself contains certain specified information or is linked to one or more other databases containing such information.
The information expected to be required for each invoice would be, for example, entered in the following fields:
1. Biller's name, address, and phone number, and possibly an account number and/or password 2. Date posted (generated automatically) 3. Invoice number 4. Name of customer 5. Particulars of customer notification method, normally e-mail 6. Total amount due 7. Due date 8. Bank account to which to deposit the payment (optional) Note that the facilitator from a linked database may automatically generate various of the field data entries for the invoice database, notably the biller's name and bank account, if the biller is a subscriber of the facilitator. The facilitator could if so directed by the biller generate automatically a series of invoice numbers for successive invoices transmitted by a given biller. Similarly, the customer's name and e-mail address can be generated automatically if the customer is a previously identified customer of the biller or is a subscriber of the facilitator.
The first (invoice-posting) session occurs as follows:
a. The biller logs on to or otherwise accesses the facilitator's web site.
b. The biller submits an invoice to the facilitator. (Note that the facilitator should preferably be able to upload .pdf, .gif, .jpg, or other suitable formatted invoice details files, possibly saved with file extension .bil.) c. The facilitator displays to the biller on the facilitator's website an acknowledgment of the bill, optionally with a confirmation code accessible to the biller.
Step (a) above may require the biller to submit sufficient input information (possibly merely a log-on identification code and a password) that enables the facilitator to compare the information against stored and registered data maintained in the facilitator's biller database.
Step (b) above may require the biller to submit sufficient input information (possibly merely a customer identification code) that enables the facilitator to compare the information against stored and registered data maintained in the facilitator's customer database.
The completion of the foregoing steps results in the creation of a database record for the invoice in the facilitator's invoice database that will contain data corresponding to each of the fields mentioned above, or some other suitable set of selected fields appropriate to the kind of transaction to which the invoice relates.
Next, the facilitator notifies the customer via e-mail of the existence of the bill or invoice and of a bill identification code required to enable the customer to retrieve particulars of the invoice. The bill identification code may preferably be automatically generated by the facilitator but conceivably could be provided by the biller as a further item of invoice-related data.
Once the customer is aware of the existence of the invoice and knows the bill identification code for the invoice, the customer may at will initiate the second (invoice review and payment) on-line session with the facilitator. The second on-line session proceeds as follows:
a. The customer accesses the facilitator's website.
b. Using the bill identification code, the customer selects a display of the invoice and may optionally download the invoice to the customer's computer.
c. Optionally, the customer elects whether to pay the invoice only in part. (Of course, the Customer may elect not to pay the invoice at all, and may log off the website at any time during the session prior to authorizing payment.) d. The customer specifies how to pay the invoice - typically by credit card or debit card, but alternatively, if a subscriber of the facilitator, by any other means agreed upon, such as digital cash payments or direct bank account debiting, possibly from a selection of available bank accounts.
e. The customer may optionally set a specific date on which payment will occur. If the biller or facilitator so requires, or as a default, payment will occur automatically on the date of the session.
f. If the payment involves an additional transfer between customer bank accounts, then the billing service facilitator may display the amount of any additional transaction fee and presumably will provide a means of obtaining approval from the customer before effecting the transfer of funds.
g. Payment follows pursuant to the manner of payment elected by the customer, upon the customer's entry of payment approval.
The foregoing series of steps pursuant to one or both sessions may be subjected routinely to suitable security and other safeguards. For example, the transaction can be processed in part through an electronic payments accreditation service such as the ClearCommerce service available from clearcommerce.com.
Once the payment of the invoice has occurred, the facilitator displays on its website a confirmation number for access by the biller to the particulars of the payment. The next time that the biller accesses the facilitator's website, the biller may check the status of invoices previously posted on the website, and will note any confirmation data posted. The biller may also note the status of unpaid invoices, and may send reminders directly via e-mail to the various customers in default of payment, or may arrange to have the facilitator do so if the latter elects to provide a reminder service.
Both billers and customers may optionally become subscribers of the facilitator. Subscribers save time and effort by avoiding having to enter the same data many times. Each subscribing biller's computer system can be connected to the facilitator's system to generate invoices automatically.
The data to be gathered by the facilitator from subscribers, when they first become subscribers, may include the following:
Biller's initial data:
1. Company name, telephone number, address, e-mail address, etc.
2. Fiscal year-end 3. Bank accounts) 4. Facilitator account or reference number (assigned by the facilitator) 5. Password for the subscriber service and/or each of the biller's bank accounts (selected by the biller but known to the facilitator) 6. Names, e-mail addresses, etc. of all customers designated by the biller, and their bill notification method (preferably e-mail) 7. (optionally) A method to generate invoice number automatically Customer's initial data:
1. Name, telephone number, address, e-mail address, etc.
2. Fiscal year-end (possibly only for commercial accounts) 3. Customer's bank accounts) 4. Facilitator account or reference number 5. Password to the subscriber service and/or to individual accounts 6. Bill notification method (e. g., via e-mail) and address (e. g., an e-mail address) While e-mail notification is clearly a preferred option, the facilitator at its option may make available alternative _g_ notification methods such as pager, text message on a cellular phone, or on-line access to the account on the facilitator's website. The system should enable any subscriber to update or correct the data of record at any time. In the case where a subscriber is both a biller and a customer, then various of the items of data listed above need be entered only once (e.g., the subscriber, if both a biller and customer, need have only one account with the facilitator, and the subscriber's bank account information need be entered only once).
Expansion, modification and refinement of the system as described thus far are possible and may be desirable. For example, the use of intelligent agents on the Internet is known;
the system could be set up so that a subscribing customer may utilize an intelligent agent facility to make payment to a biller. Such intelligent agent for example might identify the optimal way of making a payment (e. g., from the bank account with sufficient funds to make the payment, or by transferring funds from one of the customer's bank accounts to another to provide sufficient funds in a selected bank account to make the payment).
Other possible refinements include set-up of the system to enable the facilitator to generate reports for subscribers.
Reports for the biller may include, for example, periodically generated aged lists of invoices, identifying those customers who have paid their outstanding invoices and those who have not. The facilitator may keep all transaction records available for on-line access for 6 months or for some suitable period after the biller's fiscal year-end. Reports can also be made available to customer subscribers (e.g., lists within a reporting period of what has been paid to whom and what invoices remain unpaid).
Similarly, all customer transaction records may remain on-line until 6 months (say) after the fiscal year-end of the customer have elapsed, or until some specified time after the end of the calendar year.
Field of the Invention This invention relates to an Internet billing and payment system to facilitate billings and payments using the Internet.
Background of the Invention A number of commercial transactions occur on the Internet.
Many Internet-based businesses operate by offering products or services for sale on the Internet, and by receiving payment from users or purchasers typically by way of submission by the user or purchaser of credit card information to the provider of goods or services, whereupon the credit card is debited and the goods and services are provided. Encryption and verification procedures have been developed to authenticate amounts billed and transferred, parties to transactions, and other particulars.
A number of Internet-based systems exist for consolidating bills and transmitting them to a billed customer. Typically, a postal, telecommunications or financial institution will gather together bills from various billing entities (billers), and allow Internet portal access to recognized customers to pay the total amount owing, or a portion thereof. Such payment is made to the bill consolidator service provider, who then distributes the amount received to the billers. In such arrangements, the individual billers (typically retailers) and the billed customers do not have a direct communications or payment link - the link with either exists only through the bill consolidator. Credit card companies may function in this manner. A representative prior patent directed to computerized billing and payment authorization systems is U.S. patent no. 5943656 granted to Crooks et al. on 24 August 1999. An alternative bill consolidation and payment aggregation and settlement system is described in U.S. Patent 5978780 granted to Watson on 2 November 1999.
The principal problem with bill consolidation processes and facilities of the foregoing sort is that only a limited number of subscribers may use the Internet-based system, and those subscribers do not have any direct communication or transaction links with the billing entities - rather, all transactions occur with the bill consolidator. This kind of billing consolidation procedure and facility cannot be used by either billing entities or billed entities to communicate with one another and arrange submission of invoices or payment of invoices directly to one another. Furthermore, the limited subscriber list of bill consolidators means that the bill consolidators' facilities cannot be easily used by the general public via the Internet.
Summary of the Invention According to the present invention, an open billing architecture is provided that enables any billing party to communicate an invoice or bill via the billing and payment facilitator's website to any customer (or at least to any customer having an Internet address), without requiring either party to be a subscriber to the billing service facilitator's system, and without restrictive funnelling of the various transactions through a bill consolidator or the like. The term "open architecture" is used to signify that the system is available to many users, be they billers or customers or both, without the need to record any users as subscribers to the system.
According to the invention, a centralized billing service facilitator operating a website (hereinafter "facilitator") permits a biller to present its bill or invoice as a discrete payable invoice directly to the billed customer. An invoice posting procedure according to the invention is described below.
The principal proviso is, of course, that the billed customer be reachable by a suitable communications link, which as a practical matter implies that the customer should have an Internet address.
The billed customer is alerted by an incoming e-mail message or equivalent notice (e.g. by pager) that the biller has sent the bill to the facilitator. The customer then may access the facilitator's website, review the invoice, and if the particulars are correct, arrange payment of the invoice via the facilitator.
The facilitator passes on the received amount to the biller, less a transaction fee unless some other arrangement is in place for compensating the facilitator. Payment may be effected by credit card, by debiting a bank account, or by any other means acceptable to the parties to the transaction.
By proceeding in this way, both the biller and the customer may avoid the delays and expense of using the postal service.
The system presumably would, of course, be subject to the usual security and privacy measures available to protect Internet sites and transactions; firewall protection against hackers and against "denial of service" bombardment would be established, as would any other form of Internet protection applicable to businesses operating on the Internet. Future security and privacy protection measures would presumably be applied as and when available and effective.
The entire system can optionally function without passwords and without subscribers, although purchasers may be offered a subscriber option that makes available such additional services as automatic access to a subscriber's designated bank account or the like, and billers may be offered a subscriber option that further facilitates various aspects of the processing of invoice posting and payments. Further, billers would be expected by direct agreement or by implication from the fact of using the facilitator's services to agree with the facilitator that the of the facilitator may extract a transaction fee; this condition of service may be implicit in the election by the biller to use the facilities of the website operated by the facilitator.
In greater particularity, the bill-posting and bill-payment process would work according to one aspect of the invention as follows, the posting procedure of course preceding the payment procedure:
A first on-line Internet invoice-posting session occurs between the biller and the facilitator;
a second on-line Internet invoice-review-and-payment session occurs between the customer (billed party) and the facilitator.
In both sessions, the facilitator functions in reactive mode; the initiating party for the first session is the biller and the initiating party for the second session is the customer. These sessions are premised on the maintenance by the billing service facilitator of a database that itself contains certain specified information or is linked to one or more other databases containing such information.
The information expected to be required for each invoice would be, for example, entered in the following fields:
1. Biller's name, address, and phone number, and possibly an account number and/or password 2. Date posted (generated automatically) 3. Invoice number 4. Name of customer 5. Particulars of customer notification method, normally e-mail 6. Total amount due 7. Due date 8. Bank account to which to deposit the payment (optional) Note that the facilitator from a linked database may automatically generate various of the field data entries for the invoice database, notably the biller's name and bank account, if the biller is a subscriber of the facilitator. The facilitator could if so directed by the biller generate automatically a series of invoice numbers for successive invoices transmitted by a given biller. Similarly, the customer's name and e-mail address can be generated automatically if the customer is a previously identified customer of the biller or is a subscriber of the facilitator.
The first (invoice-posting) session occurs as follows:
a. The biller logs on to or otherwise accesses the facilitator's web site.
b. The biller submits an invoice to the facilitator. (Note that the facilitator should preferably be able to upload .pdf, .gif, .jpg, or other suitable formatted invoice details files, possibly saved with file extension .bil.) c. The facilitator displays to the biller on the facilitator's website an acknowledgment of the bill, optionally with a confirmation code accessible to the biller.
Step (a) above may require the biller to submit sufficient input information (possibly merely a log-on identification code and a password) that enables the facilitator to compare the information against stored and registered data maintained in the facilitator's biller database.
Step (b) above may require the biller to submit sufficient input information (possibly merely a customer identification code) that enables the facilitator to compare the information against stored and registered data maintained in the facilitator's customer database.
The completion of the foregoing steps results in the creation of a database record for the invoice in the facilitator's invoice database that will contain data corresponding to each of the fields mentioned above, or some other suitable set of selected fields appropriate to the kind of transaction to which the invoice relates.
Next, the facilitator notifies the customer via e-mail of the existence of the bill or invoice and of a bill identification code required to enable the customer to retrieve particulars of the invoice. The bill identification code may preferably be automatically generated by the facilitator but conceivably could be provided by the biller as a further item of invoice-related data.
Once the customer is aware of the existence of the invoice and knows the bill identification code for the invoice, the customer may at will initiate the second (invoice review and payment) on-line session with the facilitator. The second on-line session proceeds as follows:
a. The customer accesses the facilitator's website.
b. Using the bill identification code, the customer selects a display of the invoice and may optionally download the invoice to the customer's computer.
c. Optionally, the customer elects whether to pay the invoice only in part. (Of course, the Customer may elect not to pay the invoice at all, and may log off the website at any time during the session prior to authorizing payment.) d. The customer specifies how to pay the invoice - typically by credit card or debit card, but alternatively, if a subscriber of the facilitator, by any other means agreed upon, such as digital cash payments or direct bank account debiting, possibly from a selection of available bank accounts.
e. The customer may optionally set a specific date on which payment will occur. If the biller or facilitator so requires, or as a default, payment will occur automatically on the date of the session.
f. If the payment involves an additional transfer between customer bank accounts, then the billing service facilitator may display the amount of any additional transaction fee and presumably will provide a means of obtaining approval from the customer before effecting the transfer of funds.
g. Payment follows pursuant to the manner of payment elected by the customer, upon the customer's entry of payment approval.
The foregoing series of steps pursuant to one or both sessions may be subjected routinely to suitable security and other safeguards. For example, the transaction can be processed in part through an electronic payments accreditation service such as the ClearCommerce service available from clearcommerce.com.
Once the payment of the invoice has occurred, the facilitator displays on its website a confirmation number for access by the biller to the particulars of the payment. The next time that the biller accesses the facilitator's website, the biller may check the status of invoices previously posted on the website, and will note any confirmation data posted. The biller may also note the status of unpaid invoices, and may send reminders directly via e-mail to the various customers in default of payment, or may arrange to have the facilitator do so if the latter elects to provide a reminder service.
Both billers and customers may optionally become subscribers of the facilitator. Subscribers save time and effort by avoiding having to enter the same data many times. Each subscribing biller's computer system can be connected to the facilitator's system to generate invoices automatically.
The data to be gathered by the facilitator from subscribers, when they first become subscribers, may include the following:
Biller's initial data:
1. Company name, telephone number, address, e-mail address, etc.
2. Fiscal year-end 3. Bank accounts) 4. Facilitator account or reference number (assigned by the facilitator) 5. Password for the subscriber service and/or each of the biller's bank accounts (selected by the biller but known to the facilitator) 6. Names, e-mail addresses, etc. of all customers designated by the biller, and their bill notification method (preferably e-mail) 7. (optionally) A method to generate invoice number automatically Customer's initial data:
1. Name, telephone number, address, e-mail address, etc.
2. Fiscal year-end (possibly only for commercial accounts) 3. Customer's bank accounts) 4. Facilitator account or reference number 5. Password to the subscriber service and/or to individual accounts 6. Bill notification method (e. g., via e-mail) and address (e. g., an e-mail address) While e-mail notification is clearly a preferred option, the facilitator at its option may make available alternative _g_ notification methods such as pager, text message on a cellular phone, or on-line access to the account on the facilitator's website. The system should enable any subscriber to update or correct the data of record at any time. In the case where a subscriber is both a biller and a customer, then various of the items of data listed above need be entered only once (e.g., the subscriber, if both a biller and customer, need have only one account with the facilitator, and the subscriber's bank account information need be entered only once).
Expansion, modification and refinement of the system as described thus far are possible and may be desirable. For example, the use of intelligent agents on the Internet is known;
the system could be set up so that a subscribing customer may utilize an intelligent agent facility to make payment to a biller. Such intelligent agent for example might identify the optimal way of making a payment (e. g., from the bank account with sufficient funds to make the payment, or by transferring funds from one of the customer's bank accounts to another to provide sufficient funds in a selected bank account to make the payment).
Other possible refinements include set-up of the system to enable the facilitator to generate reports for subscribers.
Reports for the biller may include, for example, periodically generated aged lists of invoices, identifying those customers who have paid their outstanding invoices and those who have not. The facilitator may keep all transaction records available for on-line access for 6 months or for some suitable period after the biller's fiscal year-end. Reports can also be made available to customer subscribers (e.g., lists within a reporting period of what has been paid to whom and what invoices remain unpaid).
Similarly, all customer transaction records may remain on-line until 6 months (say) after the fiscal year-end of the customer have elapsed, or until some specified time after the end of the calendar year.
Subscribers who are both a biller and a customer could also have on-line access to the following types of reports generated by the facilitator, among others:
1. Reports showing billing and payments transactions in chronological order;
2. Periodic cash flow analysis;
3. Reports of interactions with other companies either generally or selectively.
The description of the foregoing system is based on the presupposition that the facilitator, billers and customers have suitable computers or terminals with Internet access via a suitable telecommunications link. The transactions described above are each individually transactions of types that conventionally occur on the Internet; what is primarily advantageous and unique about the system described is the novelty of the interrelationship between facilitator, billers and customers (both those who are subscribers and those who are not) and especially the "open architecture" approach that permits, in a preferred embodiment of the system, any biller and any customer to use the system, whether they are subscribers or not. The hardware and software platform and structure used to implement any particular system according to the invention can be the same as or generally similar to those now used for operating and accessing any E-Commerce web site from which people can order products or services on-line and/or effect on-line payments (including making credit card payments).
Note that although the foregoing system as described is intended for Internet use, it can be used in any suitable open-architecture telecommunications context.
Summary of the Diagrams Figure 1 is a block diagram representing a conventional (prior art) billing system used by a company to send individual invoices to individual customers.
Figure 2 is a block diagram representing a conventional (prior art) direct biller system used by billers to distribute invoices to customers.
Figure 3 is a block diagram representing a conventional (prior art) bill consolidator system used by companies to distribute payment information for customers.
Figure 4 is a block diagram representing the relationship between multiple companies using the system to post invoices amongst themselves within a billing and payment system according to the present invention.
Figure 5 is a flowchart representing a conventional (prior art) Internet-based invoice posting system and method, for use by a bill consolidator.
Figure 6 is a flowchart representing a preferred embodiment of an invoice posting and associated data gathering system and method according to the present invention.
Figure 7 is a flowchart illustrating a conventional (prior art) Internet-based system and method for arranging an invoice payment by a customer, for use by a direct biller, or a by bill consolidator.
Figure 8 is a flowchart representing a preferred embodiment of a system and method for invoice payment for use by a customer according to the present invention.
Description of the Invention with Reference to the Diagrams The billings and payments facilitator system and method according to a preferred embodiment of the invention comprise an integrated system and method embodying the steps, apparatus and relationships manifest in both Figures 6 and 8. For convenience, the system and method have been divided into two parts, viz (i) invoice posting (Figure 6), and (ii) invoice review and payment (Figure 8). For convenience in distinguishing the present invention from the prior art, Figures l, 2, 3, 5 and 7 respectively present prior systems and methods for direct billing (Figures 1 and 2), bill consolidation (Figure 3), invoice posting (Figure 5), and for invoice review and payment (Figure 7).
Figure 4 represents a simplified presentation of the possible dual status of any given person (corporate, firm or individual) as being both a biller and a customer in a billing and payment system according to the invention.
Referring to Figure l, in a typical unilateral billing system, a given company (biller) creates invoices as goods are delivered or as services are rendered and sends individual invoices to individual customers. Such company creates a separate invoice for each of its customers. An invoice is then sent by the company directly to the customer.
Referring to Figure 2, a given company may accumulate invoices for a given customer and send out a monthly or other periodic billing summary to the customer. As an alternative, the company may retain a billing service to look after its billings.
In either case, a single billing entity creates a separate statement of account or equivalent for every customer and sends the pertinent statement of account, invoices, etc. to respective customers. The system is a conventional unilateral billing system in either case.
Referring to Figure 3, a bill consolidator (say, a credit card company) collects invoices from various billers and sorts them by customer, sending to each customer monthly a statement of what is owing to the bill consolidator to pay the set of billings received from various billers during the preceding month for that customer. There is no link between billers and customers; the billers' links are with the bill consolidator and the customers' links are with the bill consolidator. All billing information directed to a given customer is compiled by the bill consolidator in a single invoice or statement of account and sent to the customer.
By contrast with the foregoing, pursuant to the open-architecture concept of the present invention, any biller may, using the inventive system, electronically post an invoice intended for any customer. Any billed customer may pay any bill that has been directed to the customer via the system, without being a subscriber to the system. According to a preferred embodiment of the inventive system, the biller sends invoice data to a system facilitator at the latter's website; the facilitator alerts the customer; and the customer using a bill identification code password or the like accesses the bill and may arrange direct electronic payment of same. Since, in contrast to billing consolidator systems, there is no requirement that the customer be a subscriber to the system, the system can be used by anyone who has the appropriate Internet access. And in contrast to direct billing systems of the sort illustrated in Figures 1 and 2, the open-architecture system according to the invention permits the biller to direct the biller's invoice to a given customer and to have that customer pay that biller's invoice; the system is multilateral, involving many billers and many customers.
Figure 4 illustrates an important result of this "open architecture" Internet-based billing and payment system according to the invention, viz that a given person (corporate, firm or individual) who uses the system is equally entitled to either receive an invoice or post an invoice. Furthermore, a user may have multiple dealings with multiple customers and suppliers of its own. The "open architecture" of the system groups both customers and billers together into a single pool of users who may on one occasion be billers, on another customers. Of course, some may be billers only and some customers only, but the system is fully flexible as to the possibilities.
Figure 5 illustrates a conventional Internet-based method of posting an invoice by a bill consolidator (a credit-card issuer is a typical bill consolidator). The bill consolidator maintains a database S-1 containing the requisite particulars of those billers whose billings to customers are accepted by the bill consolidator for passing on to a customer in a single integrated statement, typically a monthly statement. Such data will include, of course, a full identification of each biller, the biller's address, account number, password if appropriate, etc., and any other particulars required by the bill consolidator for its records for the set of billers whom it serves.
When a biller wishes to have an invoice paid, the biller provides invoice data to the website of the bill consolidator, who verifies the authenticity of the biller by comparison of the incoming data against the registered data in biller database S-1.
If verification of the authenticity of the biller occurs, then the data sent by the accepted biller will necessarily include an identification of the customer to whom the invoice is to be presented. The bill consolidator maintains customer data for each of the bill consolidator's customers in a database S-2. For each fresh invoice, the identification of the customer designated by the biller is compared with the data in the customer database S-2, and the authenticity of the customer is verified. Note that in this system, customers are direct customers of the bill consolidator; the transaction between biller and customer was completed when the customer presented a credit card (say) to the biller for payment for goods or services provided by the biller to the customer. The remaining transactions are between biller and bill consolidator, on the one hand, and between bill consolidator and customer, on the other hand. The biller has no obligation to know the customer or anything about the creditworthiness of the customer beyond the fact that the customer has a credit card (say). The customer database is generated by the bill consolidator as part of the bill consolidator's business.
Assuming that the customer is properly verified as an accepted customer, appropriate details of the accepted invoice are posted on the bill consolidator's website. The bill consolidator periodically, or instantaneously once an invoice has been accepted, may post such invoice or a consolidation of such invoices on the website for access by the customer. The complete set of stored invoices is maintained in an invoice database S-3.
The manner in which a customer conventionally pays a posted invoice that has been posted by a bill consolidator is reviewed further below with reference to Figure 7.
By comparison, Figure 6 illustrates the manner of posting an invoice using the facilities of a billings and payments facilitator in accordance with the principles of the present invention. Figure 6 illustrates the on-line steps and system operative once a biller accesses the website on-line. The facilitator maintains a database S-4 of particulars of all of the billers whose invoices are accepted for website posting by the facilitator. Note that in Figure 5, the customer data within customer database S-2 is customer data typically maintained by the bill consolidator, and is normally not supplied separately by the biller to the consolidator. The biller merely has to identify the essential particulars of the customer for each invoice, such essential particulars typically comprising a name, a credit card number, and a card expiry date. By contrast, the customer data in customer database S-5 in Figure 6 is typically provided entirely by the biller, and of course, is required to be updated from time to time as the biller's customer list expands.
When a biller wishes to post an invoice pursuant to the method of the present invention, the biller sends a message to this effect to the facilitator, who compares the biller identification input data with what is registered in the facilitator's biller database S-4. If the biller is identified and verified, the invoice is treated as that of an accepted biller; however, the invoice also identifies a customer, and the biller will have been obligated to provide the facilitator with suitable customer data on that same occasion, or on a previous occasion, which customer data is maintained in customer database S-5. If the customer's bill identification code is thus properly identified and verified according to the protocol established by the facilitator, then the invoice is treated as being one suitable for presentation to an accepted customer, and is posted for access by the customer (as will be more fully described with reference to Figure 8). Particulars of all of the invoices that are posted are maintained in an invoice database S-6.
Note that step 1 (identify biller) and step 2 (identify customer) can be accomplished without the need to process all of the data in the invoice; all that is required to be processed in steps 1 and 2 is biller and customer identification and verification. A "Verified" result at steps 1 and 2 permits full data relating to the invoice to be posted, but that additional data may be transmitted directly from the biller's incoming data stream to the invoice database S-6, and need not pass through verification steps 1 and 2.
Data gathering step 4 insofar as it pertains to biller and customer data may be the default first data storage step if the biller has not previously dealt with the facilitator and thus does not pass step 1 (biller identification and verification);
otherwise step 4 is implemented for biller and customer data only if an updating of such information is required. A failure to obtain a "Verified" result at step 2 (customer identification and verification) would again invoke step 4 insofar as customer identification is concerned. Step 4 (posting invoice data) occurs only after a "Verified" result is obtained at both steps 1 and 2 .
Referring to Figure 7, the flowchart reflects a sequence of invoice review and payment activities that occurs at a website operated by a direct biller or by a bill consolidator. A
customer who has received an invoice accesses the website on-line and provides customer data (name, address, e-mail address, account number, password, etc.) sufficient to identify the customer according to the protocol established by the website operator. The website operator will typically have previously stored customer data as registered data in database S-2, and will compare the customer's identification data submitted on-line to what is registered for that customer in database S-2. If there is a match, then the customer on-line to the website is verified as an authentic customer (accepted customer), and the website operator displays to the customer on-line a standard-form invoice, or a set of particulars for an invoice that is due for payment. This invoice data is obtained from an invoice database S-3 that correlates the accepted customer input data with stored invoice data associated with that accepted customer, so as to present to the customer the data associated with any invoices that are outstanding for payment. The customer has the opportunity to view the invoice data on screen, and if the customer does not accept that the invoice is payable, may either log off, or (depending upon the options available at the website) notify the website operator that the invoice is not accepted, in which case, measures designed to remedy the problem would normally be invoked. However, if the customer accepts the invoice, then the website operator displays a screen, or screen fragment, that presents to the customer the option to pay the invoice by debiting the customer's bank account. Note that if the bill consolidator operating the website is a credit card company, that company may be a bank, and the bank account to be debited may of course be maintained by that same bank.
Once payment is effected via this Internet transaction, the fact of payment is entered in the invoice database S-3 against the invoice in question, so that the invoice will be recorded thereafter as having been paid.
By contrast, Figure 8 illustrates the series of steps required for customer bill payment when a bill payment facilitation system and method according to a preferred embodiment of the present invention is used. In this case, the website is operated by a billings and payments facilitator in accordance with the present invention. Figure 8 illustrates the on-line steps and system operative once a customer accesses the website on-line.
The method reflected in Figure 8 is premised on a prior invoice posting in compliance with Figure 6, whereby billing data submitted to the facilitator's website has included accepted invoice details in respect of a fresh invoice, whereupon the facilitator has sent to the customer, preferably by e-mail, a message notifying the customer that a fresh invoice is available for viewing and payment, and communicating to the customer a bill identification code required to be submitted by the customer in order to view the invoice and arrange its payment.
Before any such message is sent to the customer, the facilitator will have previously established that it has of record sufficient data to identify and verify the customer in accordance with whatever protocol is established by the facilitator. The applicable customer data is stored in database S-5.
When a customer wishes to view a fresh invoice of which the customer has previously received notice, the customer accesses the facilitator's website on-line and submits to the facilitator the requisite customer identification data that can be compared with stored and registered data in database S-5 for those customers that are of record with the facilitator. The facilitator conducts a comparison between the input data and the stored data (step 1), and if the customer is identified and verified as one whom the facilitator is prepared to serve, the next step 2 in the on-line session occurs, namely, the comparison by the facilitator of the stored bill identification code for the invoice with that supplied by the customer. If the bill identification code is verified as authentic for a given invoice, then in step 3 the customer is able to view the invoice. Note that step 3 is implemented only if a "Verified" result follows from steps 1 and 2.
If the customer does not accept the invoice, or does not wish to pay it, the customer may log off, or if the system so provides, the customer may send a message to the biller via the facilitator that the invoice is disputed or otherwise. If, however, the customer accepts the invoice for payment, the customer provides suitable payment instructions to the facilitator (step 5) after first analysing payment options (step 4), if appropriate. (Sometimes a customer may have more than one account, or more than one means of payment that can be used, and this choice, if available, is presented to the customer in step 4 as a prelude to instructing the facilitator to effect payment pursuant to step 5.) Once the appropriate method of payment has been elected, the customer submits to the facilitator this payment information along with an instruction to pay the invoice, and the amount paid is credited against the invoice. The amount paid is credited to a selected one of the biller's bank accounts (bank accounts of both billers and customers being maintained in database S-7), less a transaction fee exacted by the facilitator.
Database S-7 may be maintained directly by the bank or banks maintaining the accounts in question, with permitted access by the facilitator to arrange authorized debit and credit transactions in the bank accounts.
Assuming that customers' bank accounts are maintained in database S-7, and that the customer may have more than one bank account (or other account with a financial institution of some sort, including credit card accounts), the various options available to the customer for paying the invoice may be presented at step 4 (analyse payment options). Further, if the system so provides, an intelligent agent may, on the customer's behalf, sample data in various of the customer' s accounts, and make a recommendation to the customer as to how to effect payment, including by way of transfer of sums of money from one customer account to another, if appropriate.
Various embellishments of the systems of Figures 5-8 are possible, and normal encryption, authentication, anti-hacker and other peripheral system components and procedures would normally be invoked to ensure that the transactions to which these flowcharts apply are authentic, properly recorded and private.
The invention is not limited to the preferred embodiment described, but is to be accorded the full scope set forth in the appended claims.
1. Reports showing billing and payments transactions in chronological order;
2. Periodic cash flow analysis;
3. Reports of interactions with other companies either generally or selectively.
The description of the foregoing system is based on the presupposition that the facilitator, billers and customers have suitable computers or terminals with Internet access via a suitable telecommunications link. The transactions described above are each individually transactions of types that conventionally occur on the Internet; what is primarily advantageous and unique about the system described is the novelty of the interrelationship between facilitator, billers and customers (both those who are subscribers and those who are not) and especially the "open architecture" approach that permits, in a preferred embodiment of the system, any biller and any customer to use the system, whether they are subscribers or not. The hardware and software platform and structure used to implement any particular system according to the invention can be the same as or generally similar to those now used for operating and accessing any E-Commerce web site from which people can order products or services on-line and/or effect on-line payments (including making credit card payments).
Note that although the foregoing system as described is intended for Internet use, it can be used in any suitable open-architecture telecommunications context.
Summary of the Diagrams Figure 1 is a block diagram representing a conventional (prior art) billing system used by a company to send individual invoices to individual customers.
Figure 2 is a block diagram representing a conventional (prior art) direct biller system used by billers to distribute invoices to customers.
Figure 3 is a block diagram representing a conventional (prior art) bill consolidator system used by companies to distribute payment information for customers.
Figure 4 is a block diagram representing the relationship between multiple companies using the system to post invoices amongst themselves within a billing and payment system according to the present invention.
Figure 5 is a flowchart representing a conventional (prior art) Internet-based invoice posting system and method, for use by a bill consolidator.
Figure 6 is a flowchart representing a preferred embodiment of an invoice posting and associated data gathering system and method according to the present invention.
Figure 7 is a flowchart illustrating a conventional (prior art) Internet-based system and method for arranging an invoice payment by a customer, for use by a direct biller, or a by bill consolidator.
Figure 8 is a flowchart representing a preferred embodiment of a system and method for invoice payment for use by a customer according to the present invention.
Description of the Invention with Reference to the Diagrams The billings and payments facilitator system and method according to a preferred embodiment of the invention comprise an integrated system and method embodying the steps, apparatus and relationships manifest in both Figures 6 and 8. For convenience, the system and method have been divided into two parts, viz (i) invoice posting (Figure 6), and (ii) invoice review and payment (Figure 8). For convenience in distinguishing the present invention from the prior art, Figures l, 2, 3, 5 and 7 respectively present prior systems and methods for direct billing (Figures 1 and 2), bill consolidation (Figure 3), invoice posting (Figure 5), and for invoice review and payment (Figure 7).
Figure 4 represents a simplified presentation of the possible dual status of any given person (corporate, firm or individual) as being both a biller and a customer in a billing and payment system according to the invention.
Referring to Figure l, in a typical unilateral billing system, a given company (biller) creates invoices as goods are delivered or as services are rendered and sends individual invoices to individual customers. Such company creates a separate invoice for each of its customers. An invoice is then sent by the company directly to the customer.
Referring to Figure 2, a given company may accumulate invoices for a given customer and send out a monthly or other periodic billing summary to the customer. As an alternative, the company may retain a billing service to look after its billings.
In either case, a single billing entity creates a separate statement of account or equivalent for every customer and sends the pertinent statement of account, invoices, etc. to respective customers. The system is a conventional unilateral billing system in either case.
Referring to Figure 3, a bill consolidator (say, a credit card company) collects invoices from various billers and sorts them by customer, sending to each customer monthly a statement of what is owing to the bill consolidator to pay the set of billings received from various billers during the preceding month for that customer. There is no link between billers and customers; the billers' links are with the bill consolidator and the customers' links are with the bill consolidator. All billing information directed to a given customer is compiled by the bill consolidator in a single invoice or statement of account and sent to the customer.
By contrast with the foregoing, pursuant to the open-architecture concept of the present invention, any biller may, using the inventive system, electronically post an invoice intended for any customer. Any billed customer may pay any bill that has been directed to the customer via the system, without being a subscriber to the system. According to a preferred embodiment of the inventive system, the biller sends invoice data to a system facilitator at the latter's website; the facilitator alerts the customer; and the customer using a bill identification code password or the like accesses the bill and may arrange direct electronic payment of same. Since, in contrast to billing consolidator systems, there is no requirement that the customer be a subscriber to the system, the system can be used by anyone who has the appropriate Internet access. And in contrast to direct billing systems of the sort illustrated in Figures 1 and 2, the open-architecture system according to the invention permits the biller to direct the biller's invoice to a given customer and to have that customer pay that biller's invoice; the system is multilateral, involving many billers and many customers.
Figure 4 illustrates an important result of this "open architecture" Internet-based billing and payment system according to the invention, viz that a given person (corporate, firm or individual) who uses the system is equally entitled to either receive an invoice or post an invoice. Furthermore, a user may have multiple dealings with multiple customers and suppliers of its own. The "open architecture" of the system groups both customers and billers together into a single pool of users who may on one occasion be billers, on another customers. Of course, some may be billers only and some customers only, but the system is fully flexible as to the possibilities.
Figure 5 illustrates a conventional Internet-based method of posting an invoice by a bill consolidator (a credit-card issuer is a typical bill consolidator). The bill consolidator maintains a database S-1 containing the requisite particulars of those billers whose billings to customers are accepted by the bill consolidator for passing on to a customer in a single integrated statement, typically a monthly statement. Such data will include, of course, a full identification of each biller, the biller's address, account number, password if appropriate, etc., and any other particulars required by the bill consolidator for its records for the set of billers whom it serves.
When a biller wishes to have an invoice paid, the biller provides invoice data to the website of the bill consolidator, who verifies the authenticity of the biller by comparison of the incoming data against the registered data in biller database S-1.
If verification of the authenticity of the biller occurs, then the data sent by the accepted biller will necessarily include an identification of the customer to whom the invoice is to be presented. The bill consolidator maintains customer data for each of the bill consolidator's customers in a database S-2. For each fresh invoice, the identification of the customer designated by the biller is compared with the data in the customer database S-2, and the authenticity of the customer is verified. Note that in this system, customers are direct customers of the bill consolidator; the transaction between biller and customer was completed when the customer presented a credit card (say) to the biller for payment for goods or services provided by the biller to the customer. The remaining transactions are between biller and bill consolidator, on the one hand, and between bill consolidator and customer, on the other hand. The biller has no obligation to know the customer or anything about the creditworthiness of the customer beyond the fact that the customer has a credit card (say). The customer database is generated by the bill consolidator as part of the bill consolidator's business.
Assuming that the customer is properly verified as an accepted customer, appropriate details of the accepted invoice are posted on the bill consolidator's website. The bill consolidator periodically, or instantaneously once an invoice has been accepted, may post such invoice or a consolidation of such invoices on the website for access by the customer. The complete set of stored invoices is maintained in an invoice database S-3.
The manner in which a customer conventionally pays a posted invoice that has been posted by a bill consolidator is reviewed further below with reference to Figure 7.
By comparison, Figure 6 illustrates the manner of posting an invoice using the facilities of a billings and payments facilitator in accordance with the principles of the present invention. Figure 6 illustrates the on-line steps and system operative once a biller accesses the website on-line. The facilitator maintains a database S-4 of particulars of all of the billers whose invoices are accepted for website posting by the facilitator. Note that in Figure 5, the customer data within customer database S-2 is customer data typically maintained by the bill consolidator, and is normally not supplied separately by the biller to the consolidator. The biller merely has to identify the essential particulars of the customer for each invoice, such essential particulars typically comprising a name, a credit card number, and a card expiry date. By contrast, the customer data in customer database S-5 in Figure 6 is typically provided entirely by the biller, and of course, is required to be updated from time to time as the biller's customer list expands.
When a biller wishes to post an invoice pursuant to the method of the present invention, the biller sends a message to this effect to the facilitator, who compares the biller identification input data with what is registered in the facilitator's biller database S-4. If the biller is identified and verified, the invoice is treated as that of an accepted biller; however, the invoice also identifies a customer, and the biller will have been obligated to provide the facilitator with suitable customer data on that same occasion, or on a previous occasion, which customer data is maintained in customer database S-5. If the customer's bill identification code is thus properly identified and verified according to the protocol established by the facilitator, then the invoice is treated as being one suitable for presentation to an accepted customer, and is posted for access by the customer (as will be more fully described with reference to Figure 8). Particulars of all of the invoices that are posted are maintained in an invoice database S-6.
Note that step 1 (identify biller) and step 2 (identify customer) can be accomplished without the need to process all of the data in the invoice; all that is required to be processed in steps 1 and 2 is biller and customer identification and verification. A "Verified" result at steps 1 and 2 permits full data relating to the invoice to be posted, but that additional data may be transmitted directly from the biller's incoming data stream to the invoice database S-6, and need not pass through verification steps 1 and 2.
Data gathering step 4 insofar as it pertains to biller and customer data may be the default first data storage step if the biller has not previously dealt with the facilitator and thus does not pass step 1 (biller identification and verification);
otherwise step 4 is implemented for biller and customer data only if an updating of such information is required. A failure to obtain a "Verified" result at step 2 (customer identification and verification) would again invoke step 4 insofar as customer identification is concerned. Step 4 (posting invoice data) occurs only after a "Verified" result is obtained at both steps 1 and 2 .
Referring to Figure 7, the flowchart reflects a sequence of invoice review and payment activities that occurs at a website operated by a direct biller or by a bill consolidator. A
customer who has received an invoice accesses the website on-line and provides customer data (name, address, e-mail address, account number, password, etc.) sufficient to identify the customer according to the protocol established by the website operator. The website operator will typically have previously stored customer data as registered data in database S-2, and will compare the customer's identification data submitted on-line to what is registered for that customer in database S-2. If there is a match, then the customer on-line to the website is verified as an authentic customer (accepted customer), and the website operator displays to the customer on-line a standard-form invoice, or a set of particulars for an invoice that is due for payment. This invoice data is obtained from an invoice database S-3 that correlates the accepted customer input data with stored invoice data associated with that accepted customer, so as to present to the customer the data associated with any invoices that are outstanding for payment. The customer has the opportunity to view the invoice data on screen, and if the customer does not accept that the invoice is payable, may either log off, or (depending upon the options available at the website) notify the website operator that the invoice is not accepted, in which case, measures designed to remedy the problem would normally be invoked. However, if the customer accepts the invoice, then the website operator displays a screen, or screen fragment, that presents to the customer the option to pay the invoice by debiting the customer's bank account. Note that if the bill consolidator operating the website is a credit card company, that company may be a bank, and the bank account to be debited may of course be maintained by that same bank.
Once payment is effected via this Internet transaction, the fact of payment is entered in the invoice database S-3 against the invoice in question, so that the invoice will be recorded thereafter as having been paid.
By contrast, Figure 8 illustrates the series of steps required for customer bill payment when a bill payment facilitation system and method according to a preferred embodiment of the present invention is used. In this case, the website is operated by a billings and payments facilitator in accordance with the present invention. Figure 8 illustrates the on-line steps and system operative once a customer accesses the website on-line.
The method reflected in Figure 8 is premised on a prior invoice posting in compliance with Figure 6, whereby billing data submitted to the facilitator's website has included accepted invoice details in respect of a fresh invoice, whereupon the facilitator has sent to the customer, preferably by e-mail, a message notifying the customer that a fresh invoice is available for viewing and payment, and communicating to the customer a bill identification code required to be submitted by the customer in order to view the invoice and arrange its payment.
Before any such message is sent to the customer, the facilitator will have previously established that it has of record sufficient data to identify and verify the customer in accordance with whatever protocol is established by the facilitator. The applicable customer data is stored in database S-5.
When a customer wishes to view a fresh invoice of which the customer has previously received notice, the customer accesses the facilitator's website on-line and submits to the facilitator the requisite customer identification data that can be compared with stored and registered data in database S-5 for those customers that are of record with the facilitator. The facilitator conducts a comparison between the input data and the stored data (step 1), and if the customer is identified and verified as one whom the facilitator is prepared to serve, the next step 2 in the on-line session occurs, namely, the comparison by the facilitator of the stored bill identification code for the invoice with that supplied by the customer. If the bill identification code is verified as authentic for a given invoice, then in step 3 the customer is able to view the invoice. Note that step 3 is implemented only if a "Verified" result follows from steps 1 and 2.
If the customer does not accept the invoice, or does not wish to pay it, the customer may log off, or if the system so provides, the customer may send a message to the biller via the facilitator that the invoice is disputed or otherwise. If, however, the customer accepts the invoice for payment, the customer provides suitable payment instructions to the facilitator (step 5) after first analysing payment options (step 4), if appropriate. (Sometimes a customer may have more than one account, or more than one means of payment that can be used, and this choice, if available, is presented to the customer in step 4 as a prelude to instructing the facilitator to effect payment pursuant to step 5.) Once the appropriate method of payment has been elected, the customer submits to the facilitator this payment information along with an instruction to pay the invoice, and the amount paid is credited against the invoice. The amount paid is credited to a selected one of the biller's bank accounts (bank accounts of both billers and customers being maintained in database S-7), less a transaction fee exacted by the facilitator.
Database S-7 may be maintained directly by the bank or banks maintaining the accounts in question, with permitted access by the facilitator to arrange authorized debit and credit transactions in the bank accounts.
Assuming that customers' bank accounts are maintained in database S-7, and that the customer may have more than one bank account (or other account with a financial institution of some sort, including credit card accounts), the various options available to the customer for paying the invoice may be presented at step 4 (analyse payment options). Further, if the system so provides, an intelligent agent may, on the customer's behalf, sample data in various of the customer' s accounts, and make a recommendation to the customer as to how to effect payment, including by way of transfer of sums of money from one customer account to another, if appropriate.
Various embellishments of the systems of Figures 5-8 are possible, and normal encryption, authentication, anti-hacker and other peripheral system components and procedures would normally be invoked to ensure that the transactions to which these flowcharts apply are authentic, properly recorded and private.
The invention is not limited to the preferred embodiment described, but is to be accorded the full scope set forth in the appended claims.
Claims (6)
1. An open-architecture billings and payments facilitation system for use with a telecommunications network and user-operated by means of computers.
2. A system as defined in claim 1 wherein the telecommunications network is the Internet.
3. A system as defined in claim 2 including an Internet-accessible website system interactive on-line with a multiplicity of billers and a multiplicity of customers.
4. A system as defined in claim 3 wherein the website system includes means for posting invoices received from billers, means for alerting respective customers that invoices respectively directed to such customers have been posted, and means for displaying to such customers particulars of such posted invoices.
5. A system as defined in any of the preceding claims wherein the website system includes means operable by customers to identify and pay discrete invoices posted, and means to transfer payment funds less applicable transaction fees to the respective billers.
6. A method of posting and paying invoices via the Internet comprising:
establishing an interactive website;
maintaining at least one database including selected particulars of individual billers and individual customers;
receiving data from billers relating to biller identification, customers of each biller, and particulars of each invoice rendered by a biller to a designated one of biller's customers;
posting data representing particulars of each invoice for access by the customer identified in the invoice;
notifying such customer that an invoice has been posted;
displaying the posted invoice to such customer upon receipt of such customer's verification of identity and right of access to the invoice;
debiting an account identified by such customer for payment of such invoice; and transferring to a designated account of such biller the amount paid by the customer, optionally less a transaction fee.
establishing an interactive website;
maintaining at least one database including selected particulars of individual billers and individual customers;
receiving data from billers relating to biller identification, customers of each biller, and particulars of each invoice rendered by a biller to a designated one of biller's customers;
posting data representing particulars of each invoice for access by the customer identified in the invoice;
notifying such customer that an invoice has been posted;
displaying the posted invoice to such customer upon receipt of such customer's verification of identity and right of access to the invoice;
debiting an account identified by such customer for payment of such invoice; and transferring to a designated account of such biller the amount paid by the customer, optionally less a transaction fee.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA 2306521 CA2306521A1 (en) | 2000-04-20 | 2000-04-20 | Internet billing and payment system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CA 2306521 CA2306521A1 (en) | 2000-04-20 | 2000-04-20 | Internet billing and payment system |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2306521A1 true CA2306521A1 (en) | 2001-10-20 |
Family
ID=4165985
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA 2306521 Withdrawn CA2306521A1 (en) | 2000-04-20 | 2000-04-20 | Internet billing and payment system |
Country Status (1)
| Country | Link |
|---|---|
| CA (1) | CA2306521A1 (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8751387B2 (en) | 2008-09-09 | 2014-06-10 | Ebay Inc. | Payment application framework |
| AU2013205573B2 (en) * | 2008-09-09 | 2015-09-24 | Paypal, Inc. | Payment application framework |
| US11455603B2 (en) | 2005-03-31 | 2022-09-27 | Paypal, Inc. | Payment via financial service provider using network-based device |
-
2000
- 2000-04-20 CA CA 2306521 patent/CA2306521A1/en not_active Withdrawn
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11455603B2 (en) | 2005-03-31 | 2022-09-27 | Paypal, Inc. | Payment via financial service provider using network-based device |
| US8751387B2 (en) | 2008-09-09 | 2014-06-10 | Ebay Inc. | Payment application framework |
| AU2013205573B2 (en) * | 2008-09-09 | 2015-09-24 | Paypal, Inc. | Payment application framework |
| AU2013205572B2 (en) * | 2008-09-09 | 2015-09-24 | Paypal, Inc. | Payment application framework |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| EP0996914B1 (en) | Electronic bill presentment and payment system which deters cheating by employing hashes and digital signatures | |
| US7676432B2 (en) | Methods and apparatus for transacting electronic commerce using account hierarchy and locking of accounts | |
| US7720760B1 (en) | Consumer-directed financial transfers using automated clearinghouse networks | |
| AU785092B2 (en) | Push model internet bill presentment and payment system | |
| US20200126076A1 (en) | Methods for performing internet processes using global positioning and other means | |
| US7177830B2 (en) | On-line payment system | |
| US6324525B1 (en) | Settlement of aggregated electronic transactions over a network | |
| US8352365B1 (en) | System and method for electronic bill presentment using a third party | |
| CA2437507C (en) | Method and system for completing a transaction between a customer and a merchant | |
| US20010044764A1 (en) | Accepting and processing electronic checks authorized via a public network | |
| US20030216996A1 (en) | Methods and systems for providing financial payment services | |
| US20040019563A1 (en) | Purchasing on the internet using verified order information and bank payment assurance | |
| WO2002017181A1 (en) | Electronic payment methods | |
| WO2003096252A1 (en) | Purchasing on the internet using verified order information and bank payment assurance | |
| US20060143122A1 (en) | Purchasing on the internet using verified order information and bank payment assurance | |
| US20020133466A1 (en) | Internet payment system | |
| CA2306521A1 (en) | Internet billing and payment system | |
| EP1101209A1 (en) | An automated payment system for execution and settlement of network purchase transactions | |
| AU2002247093B8 (en) | Method and system for completing a transaction between a customer and a merchant | |
| JP2002150198A (en) | Proxy collecting system for credit and proxy collecting method therefor | |
| AU2002247093A1 (en) | Method and system for completing a transaction between a customer and a merchant |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| AZWI | Withdrawn application |