METHOD OF TRANSACTING ACCOUNT STATEMENTS
Technical Field
The present invention relates to a method for transacting account statements via a network.
Background and Summary of the Invention
It is becoming more common to conduct bank transactions, such as paying invoices, via the Internet. Despite the increase of Internet banking, most service providers are sending out invoices to the customers. This procedure is very costly to the service providers. It is also costly for the service providers to collect on the outstanding invoices. There is a need for a reliable and efficient system that takes full advantage of Internet banking and that ensures that outstanding invoices are paid without requiring the service providers to send out invoices.
The present invention provides a solution to the above-outlined problems. More particularly, the method is for the payment of outstanding invoices. The method comprises forming an agreement between a payer/customer and a payee/service provider so that the payer is bound to review and pay payer's outstanding account statement on line to the payee. The statement is displayed on a website of the payee. The payer selects a transaction code of a transaction and enters a bank website of the payer. The payer pays the outstanding transaction by pasting the transaction code directly on the website of the payer's bank.
Brief Description of the Drawings
Fig. 1 is a schematic flow diagram of some of the events of the present invention; Fig. 2 is a schematic view of a web site display; and
Fig. 3 is a schematic flow diagram of the information flow of the present invention.
Detailed Description With reference to Figs. 1-3, the method 10 of the present invention includes an agreement step 14 in which a payer 12, such as a customer, enters into an agreement with a service provider 16, such as a utility or telephone company. Once the agreement 14 has been formed, the payer 12 is bound to visit a website 17 of the service provider 16 to retrieve, display and pay outstanding account statements. If the payer 12 does not retrieve the account statements according to the agreement 14, the service provider 16 may initiate collection proceedings. The agreement 14 may also stipulate that the payer 12 will not receive an invoice but a transaction code instead that is published on the service provider's website. If the website 17 goes down, the agreement 14 may provide that the service provider 16 must send a message, including a list of transactions that are due, to one or two email addresses of the payer 12 so that the payer 12 is aware of the malfunctioning website 17 and upcoming deadlines for payments. It is particularly important for the payer 12 to know if the website 17 is down when there are many transactions close to the payment due date. In this case, the payer 12 may copy the transaction information from the automatic email and paste the transaction information to the website of the payer's bank and carry out the payment to the service provider 16 although the website 17 is down. When the agreement so stipulates, the information may be sent by telephone text message. The information may also be sent by cable or satellite networks to the customer that payment information/ invoices are published and are required to be paid within, for example, three days.
When using the method 10, the payer 12 first enters the website by identifying him/herself in an identification step 18 with, for example, a password to gain access to the website if the website 17 is protected from unauthorized public use. The password may either be a confidential code or a public code. Payers with a public code may go to the website and obtain the account statements directly from the website and the identity of the payer could be used as the password code. The public password provides some protection for the owner of the accounts also because an unauthorized user of the website will not know who the public password belongs to and what the transaction concerns.
When the identification password is confidential, the identification step of the payer 12 not only prevents unauthorized use but also enables the service provider to know which account statements to display in a display step 20. An example of what could be displayed in the display step 20 is shown in Fig. 2. Fig. 2 shows a statement 22 that includes a transaction number column 24, an account number column 26, a due date column 28 and an amount column 30. The column 24 may include an OCR number, for optical reading, which is the service provider's code to identify each transaction relating to the payer 12. The account number column 26 lists to which account number the payer 12 should pay and the due date column 28 indicates the date on which the payment is due. For example, a transaction 25 in the transaction column 24 may be payable to a specific account number 27 and have a due date 29 and an outstanding amount 31. There may also be a link to an account identifier website so that the payer 12 can identify to whom the account number belongs before money is transferred to the account of the account number. The amount column 30 shows how much the payer should pay. The statement 22 may not only display all the account statements but may also have an invoice
button 32 to display the entire invoice, for the transaction that is selected on the statement 22, and to print the invoice if so desired by the payer 12. Any transaction that already has been paid may be displayed in a more gray or dim color so that the payer 12 knows that the statement has been paid and received by the service provider 16. The invoice may be printed for the selected transaction because the information from the statement 22 may be copied and inserted into a standard invoice format that the payer 12 may retrieve and print. As indicated above, if the payer 12 does not pay through Internet banking but prefers to pay manually through the payer's bank, the payer 12 may print the invoices. The payer 12 may also print the text string only, with the information from the statement 22 that is used on the invoice .
With reference to Fig. 1, the payer 12 may simply copy, in a copy step 34 by selecting, for example, by entering the command control C or by highlighting the desired text/number string, the outstanding transaction 25 or transactions and then enter a website 36 of the payer's Internet bank. The information may also be copied to the payer's own database if the payer would like to store all the transaction on, for example, a hard disk. Once the website 36 is displayed and is ready for payment transactions, the payer 12 may paste 38 the copied information 64 directly onto a transaction code area 37 of the website 36, by, for example, using the command control V, and then pay 40 the outstanding account statement in a conventional manner via the Internet. When the payee 16 receives the information 64 from the payee's bank, the payee may identify the transaction 25 by reviewing the transaction code 64. An important feature is that there is no need for the service provider 16 to provide and mail an invoice for the payment to be carried out by the payer. This saves a substantial amount of resources and money
for the service provider 16 and the payment procedure is very convenient for the payer 12.
With reference to Fig. 3, the service provider 16 has an elaborate data system 50 including an order database 52 that is continuously updated with information about each payer 12. For example, the database 52 may include information about every payer and every order or service that have been carried out . A copy of the database 52 may be sent via an integrator to a preliminary invoice file 54 and to a document 56, such as an XML or Excel compatible document, with a graphical interface or in a suitable program such as C++ program. The file 54 may also be continuously updated, such as every five seconds by using such scrip in an integrator, with changes that have occurred in the database 52. In this way, the file 54 is acting as a mirror of the database 52. Some of the reasons for sending copies include the duty to maintain proper record keeping and for bookkeeping purposes. The document 56 may have fields 58 for a transaction code 64, identification number 66, account number 68, due date 70 and the amount 72 due for the service that has been carried out . The code 64 may have alphabetical and numerical characters. This means that it is possible to build in the authorization scope of the payer 12 into the code. More than one service provider may use the same website because the code 64 makes it possible to use a large number of combinations.
The document 56 may also include information 57 outside a firewall 59 that may be transferred to various places, such as the website 60, located outside the firewall 59. An important feature is that the original database 52 is behind the fire wall 59 and only a copy of certain portions 61 of the database 52 is used on the outside of the firewall 59. If a transaction, such as the transaction 25, includes the transaction code 64 and the code 64 has certain characteristics, some of the
fields 58' are automatically transferred to the service provider's website 60 and to a definitive invoice file 62. For example, the fields 66, 68, 70, 72 of the transaction 25 may be copied to the website 60. The file 62 only includes the digital information that is necessary produce an invoice if so required. Whether a transaction includes the code 64 or not depends upon whether the payer 12 has entered the agreement 14 with the service provider 16 because the agreement 14 provides the code 64. The invoice file 62 stores each transaction and can be used when the payer would like to have an invoice printed. However, as mentioned above, it is not necessary for the service provider 16 to print an invoice for each transaction since the transactions information of the code 64 is automatically transferred to the website 36 of the Internet bank and the payer 12 is obligated to retrieve the information from the website 60 and transfer that information to the website 36. For each transaction that has the code 64, no invoice is automatically printed and the payer 12 must manually active the invoice button 32 to get the invoice printed. If the payer 12 has no code, and thus has not entered into the agreement 14 with the service provider 16, the service 16 must send out invoices to the payer in the conventional way.
The transaction code 25 may include a special command 80 so that when the payer 12 double clicks on the code 25 with a mouse, certain portions of an invoice is printed out. For example, the command 80 may print out the specifics behind the amount 29 such as exactly specifying what is included in the transaction and the amount 29. By only printing out selected portions on the invoice, the integrity of the payer 12 may remain since the identity of the payer 12 may be eliminated. The payer 12 may even use a fictitious name to remain confidential or the address of the payer 12 may have been removed.
The same transaction code 25 may be used by several service providers 16 that may use different invoicing systems. In this way, the identification code 18 of the payer 12 when the payer 12 enters a website 17 may trigger the display of other transactions from other service providers that are using the same transaction code 25. In other words, the payer 12 may display the outstanding invoices to other service providers, that have agreed to use the same transaction code 25, by simply entering the transaction code 25 on the website 17 of one of the service providers that are part of the same service provider network or agreement . This enables the coordination of several different invoicing systems and the payer 12 only needs to enter one of the web-sites 17 to see a list of other outstanding transactions to service providers other than the service provider 16. For example, the agreement 14 may stipulate which service providers that are part of the system 10. It is also possible, that the coordination may take place without the need for the agreement 14.
The system 10 may also send reminders to the payer by a message service such as SMS that is sent out via the mobile telephone network to a mobile telephone of the payer 12. More advanced telephones such as 3G may be able to display the specification of the invoices.
While the present invention has been described in accordance with preferred compositions and embodiments, it is to be understood that certain substitutions and alterations may be made thereto without departing from the spirit and scope of the following claims .