Patent Application
20120158583
The field generally relates to bank transfer and more specifically relates to online bank transfer using an identifier token.
In the modern world, most of the payment processes such as insurance payment, telephone payment, retail payment, utility services related payments, and the like happen through online payments. For an online payment to be made for the above services, the companies associated with the above services may need to generate invoices. On receiving the invoices from the associated companies, the invoice recipient (i.e., a payer) makes a payment through modern banking processes such as mobile banking, online banking and telephone banking or by conventional means in the branch of a bank.
Sometimes, the companies issue invoices to an end customer along with a prefilled bank form for manual payment. As a result, the customer may have to make a payment through manual credit transfer between the customer account and the account of the invoicing company. Manual credit transfer is a tedious process for the customer as the customer may have to enter all the details in the fields of the bank transfer form (e.g., amount, bank sort code, account number, type of account, invoice number or other reference to what is paid) manually.
There may be instances where erroneous data is entered in the bank transfer form. For instance, if the customer makes an error in entering the account number associated with the invoicing company, the amount may get credited to the wrong account. Errors may also occur when bank personnel manually transfer the information from a paper based credit transfer request into internal banking solutions like teller applications. Another example of the impact of erroneous data is when a customer makes an error when entering the invoice reference, in such case the payee is not able to link the payment to the right customer to reconcile the outstanding invoice amount with the customer's account at the payee.
Various embodiments of systems and methods for automated bank transfers using an identifier token are described herein. The methods and systems involve generating an invoice with an identifier token at a payee, the identifier token referencing bank transfer information of the payee, updating an invoice repository with the invoice and the identifier token and on updating, generating a notification to the payer, the notification including the identifier token.
On receiving the printed invoice respectively the notification at the computing device of the payer, the payer logging to a bank associated with himself, retrieving payment information associated with the invoice by entering the identifier token at the computing device of the payer, initiating a payment process at the computing device of the payer based on the retrieved payment information, and executing the payment process. In one embodiment, the payer receives a printed invoice as the notification.
These and other benefits and features of embodiments of the invention will be apparent upon consideration of the following detailed description of preferred embodiments thereof, presented in connection with the following drawings.
The claims set forth the embodiments of the invention with particularity. The invention is illustrated by way of example and not by way of limitation in the figures of the accompanying drawings in which like references indicate similar elements. The embodiments, together with their advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings.
Embodiments of techniques for automated bank transfers using identifier tokens are described herein. In the following description, numerous specific details are set forth to provide a thorough understanding of various embodiments. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details, or with other methods, components, materials, etc. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of the invention.
Reference throughout this specification to “one embodiment”, “this embodiment” and similar phrases, means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, the appearances of these phrases in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, the particular features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.
An invoice is a document issued by a supplier or payee to a customer or payer indicating the invoice number, the product, quantities, and agreed upon prices for products or services that the supplier has provided to the customer. The invoice indicates the payment amount according to the payment terms as agreed between the supplier and the customer and the bank details of the payee identifying the bank account where the payer is asked to pay the outstanding amount of the invoice. The bank details may include information like such as the name of the bank of the payee, the sort code of the bank, the account number and the like. The invoice may include an identifier token. The identifier token refers to the bank transfer information associated with the supplier in an invoice repository. The identifier token may be in the form of a bar code, a radio frequency identifier (RFID) tag, a printed, character-based identifier and the like. The invoice may include customer or payer data such as the name of the customer, the address of the customer, the telephone number of the customer. According to one embodiment, the invoice, along with the identifier token, is loaded on to an invoice repository. A notification is generated to the customer once the invoice and the identifier token are loaded on to the invoice repository. The notification includes the identifier token. According to one embodiment, the customer or payer may use the identifier token to initiate a bank transfer to execute the payment due to the supplier or payee.
According to one embodiment, initiating the payment includes reading the identifier token in the invoice and based on the identifier token retrieving bank transfer information from the invoice repository. The retrieved bank transfer information is used to fill the bank transfer form for making a payment. By filling the bank transfer information in this manner, entering erroneous data in the bank transfer form may be prevented.
According to one embodiment, the customer or payer retrieves unprocessed invoices from the invoice repository. The invoices may be retrieved by mapping a bank customer ID of the payer to the customer ID of the payer stored in the invoice repository. The payer may then select an invoice from a list of unprocessed invoices to make a payment.
According to another embodiment of the invention, the payment information retrieved from the invoice repository includes the bank transfer information of the payee which may be automatically filled in a bank transfer form when the user the initiates the payment.
According to another embodiment, initiating the payment process by the payer includes using a printed copy of the invoice sent by the payee and the identifier token in the invoice to make a payment at the bank through teller applications or using RFID tag or barcode scanners. The teller applications or the RFID tag or barcode scanners read the identifier token and retrieve the payment information from the invoice repository and fill the bank transfer form automatically.
According to yet another embodiment, the customer initiates payment through online banking, mobile banking and self service terminals and so on. In such cases, the identifier token is read by a device such as a scanner or a camera of a mobile device.
Some embodiments of the invention may include the above-described methods being written as one or more software components. These components, and the functionality associated with each, may be used by client, server, distributed, or peer computer systems. These components may be written in a computer language corresponding to one or more programming languages such as, functional, declarative, procedural, object-oriented, lower level languages and the like. They may be linked to other components via various application programming interfaces and then compiled into one complete application for a server or a client. Alternatively, the components may be implemented in server and client applications. Further, these components may be linked together via various distributed programming protocols. Some example embodiments of the invention may include remote procedure calls being used to implement one or more of these components across a distributed programming environment. For example, a logic level may reside on a first computer system that is remotely located from a second computer system containing an interface level (e.g., a graphical user interface). These first and second computer systems can be configured in a server-client, peer-to-peer, or some other configuration. The clients can vary in complexity from mobile and handheld devices, to thin clients and on to thick clients or even other servers.
The above-illustrated software components are tangibly stored on a computer readable storage medium as instructions. The term “computer readable storage medium” should be taken to include a single medium or multiple media that stores one or more sets of instructions. The term “computer readable storage medium” should be taken to include any physical article that is capable of undergoing a set of physical changes to physically store, encode, or otherwise carry a set of instructions for execution by a computer system which causes the computer system to perform any of the methods or process steps described, represented, or illustrated herein. Examples of computer-readable media include, but are not limited to: magnetic media, such as hard disks, floppy disks, and magnetic tape; optical media such as CD-ROMs, DVDs and holographic devices; magneto-optical media; and hardware devices that are specially configured to store and execute, such as application-specific integrated circuits (“ASICs”), programmable logic devices (“PLDs”) and ROM and RAM devices. Examples of computer readable instructions include machine code, such as produced by a compiler, and files containing higher-level code that are executed by a computer using an interpreter. For example, an embodiment of the invention may be implemented using Java, C++, or other object-oriented programming language and development tools. Another embodiment of the invention may be implemented in hard-wired circuitry in place of, or in combination with machine readable software instructions.
A data source is an information resource. Data sources include sources of data that enable data storage and retrieval. Data sources may include databases, such as, relational, transactional, hierarchical, multi-dimensional (e.g., OLAP), object oriented databases, and the like. Further data sources include tabular data (e.g., spreadsheets, delimited text files), data tagged with a markup language (e.g., XML data), transactional data, unstructured data (e.g., text files, screen scrapings), hierarchical data (e.g., data in a file system, XML data), files, a plurality of reports, and any other data source accessible through an established protocol, such as, Open DataBase Connectivity (ODBC), produced by an underlying software system (e.g., ERP system), and the like. Data sources may also include a data source where the data is not tangibly stored or otherwise ephemeral such as data streams, broadcast data, and the like. These data sources can include associated data foundations, semantic layers, management systems, security systems and so on.
In the above description, numerous specific details are set forth to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that the invention can be practiced without one or more of the specific details or with other methods, components, techniques, etc. In other instances, well-known operations or structures are not shown or described in detail to avoid obscuring aspects of the invention.
Although the processes illustrated and described herein include series of steps, it will be appreciated that the different embodiments of the present invention are not limited by the illustrated ordering of steps, as some steps may occur in different orders, some concurrently with other steps apart from that shown and described herein. In addition, not all illustrated steps may be required to implement a methodology in accordance with the present invention. Moreover, it will be appreciated that the processes may be implemented in association with the apparatus and systems illustrated and described herein as well as in association with other systems not illustrated.
The above descriptions and illustrations of embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize. These modifications can be made to the invention in light of the above detailed description. Rather, the scope of the invention is to be determined by the following claims, which are to be interpreted in accordance with established doctrines of claim construction.
