Patent Application
20100049643
Aspects of the disclosure relate to attachment of electronic documents to online bill payment records.
Online bill payment (“billpay”) has become a common capability in banks and other financial institutions that offer e-commerce websites. Typically, an internet website platform is used to facilitate payment, by a payor to a payee, of bills and debts. Payors and payees may include consumers, small business customers and others. Billpay may encompass payment of bills, debts and other monetary transactions.
Payments may be effected by paper or electronic check, electronic fund transfer, third party payment network such as the Automated Clearinghouse (“ACH”), general ledger transfer in a closed-loop payments network such as PayPal®, or through other electronic means for effecting fund transfer between parties.
Some existing billpay platforms allow payors to enter text-only messages which can be either delivered electronically with the payment information or as typewritten text on a paper check.
When a payor makes a payment using paper instrument (such as a check) and transmits the payment by postal service or courier, the payor may include any type of document that a payor might desire. The payment may include a signed contract, enrollment form, payment stub, etc.
It would be desirable, therefore, to provide apparatus and methods for attaching documents to online billpay records.
It is an object of this invention to provide apparatus and methods for attaching documents and text/comment fields to online billpay records. Apparatus and methods for electronically attaching information to a transaction between a payor and a payee are therefore provided. The apparatus and methods may involve receiving an electronic request from the payor. The request may be a request to transmit funds to the payee. The payor may attach a data object to an electronic record associated with the transaction. The record identifier may be any suitable data, such as a transaction identification number, a data record serial number, a payor identifier and a payee identifier. The data object may include information that the payor selects. The information may relate to the transaction, terms of the transaction, prior communications between the payer and the payee, prior communications among the payer, the payee and a third party or any other suitable communication or event. The data object may be an electronic file, an electronic folder, or any other suitable data structure. The data object may be formatted as an image, text, audio, video or any other suitable format. The apparatus and methods may include establishing an electronic link between the data object and the payee.
Some embodiments of the invention may involve providing access to online billpay information that corresponds to a transaction between a payer and a payee. The apparatus and methods may involve receiving a data object that the payer has selected for inclusion in the transaction. The data object may be stored in a database. A pointer may be provided. The pointer may point from a stored record of the transaction to the data object. A request for the billpay information may be received from the payer. In response to the request, the billpay information may be provided to the payer. Once provided, notification may be sent to the payee indicating that the billpay information has been provided to the payer, as a confirmation of receipt.
The objects and advantages of the invention will be apparent upon consideration of the following detailed description, taken in conjunction with the accompanying drawings, in which like reference characters refer to like parts throughout, and in which:
Apparatus and methods for improving online bill payment processes are provided. Online bill payment typically involves a paying party (“payor”), an intermediary (such as a bank, a billpay service or a billpay network) and a payee. In some embodiments, the apparatus and methods may provide optional file attachments that may be communicated from a payor (initiator) to a payee (recipient). Such attachments might include a signed contract for products or services, a payment stub with descriptive details of the payment, a photo of an item being purchased, or any other document that the payor wishes to send in connection with the payment transaction. In other embodiments, the data to be passed from payor to payee with the payment could be comprised of one or more text/comment fields.
Attachments may take the form of electronic files. The files may be uploaded to a payment intermediary, such as a bank, a billpay service, a billpay network, or any other suitable intermediary. The attachments may originate as a file from the payor's computer, a scan from a scanner, a fax, a photo, an audio and/or video recording, or any other means of electronic document capture. An attachment may be in any suitable data format, such as DOC, PDF, TIFF, WAV, MP3, or JPEG.
In some embodiments of the invention, the payment intermediary may set limits on the attachments, such as size, file type, etc. The intermediary may scan the attachment for malware or inappropriate content to prevent intentional or unintentional dispersion of malicious software code, digital rights violations, or harassing images or content.
Furthermore, the attachment may be made available to the payee whether or not the payee is a customer or member of the payment intermediary (bank, network, or otherwise) and whether the payment was made electronically (e.g., by Automated Clearing House (“ACH”) or other method) or by paper (check, draft, etc.) In the case of electronic payment, the payee may be provided with a preferably secure link that would enable the payee to view or download the attachment. In the case of paper payment, the payee may be provided with instructions and a file-code or link-name that would take the payee to view or download the attachment. In the case of paper payment, the payee may be provided with a paper copy of the attachment.
In the case of one or more text/comment fields comprising the attachment, the contents of the field(s) could be passed directly in the electronic payment record, space permitting according to accepted industry or party standards, or could be made available for retrieval via a two-step or three-step process as detailed below.
Some embodiments may include a two-step attachment/notification process in connection with the attachment. In the two-step attachment/notification process, the first step may be that a payor attaches the attachment to a payment. The second step may be that the intermediary notifies the payee about the attachment. Some embodiments may include a three-step attachment/notification process. The three-step attachment/notification process is similar to the two-step attachment/notification process, but may include, as a third step, that the intermediary notifies the payor that the payee has viewed or retrieved a copy of the attachment. The notifications may be executed by any suitable paper or electronic communication, including postal letter, electronic mail, text message, telephone, fax or any other suitable communication. The notification may be automatically stored in a database for future reference.
In certain embodiments of the invention, the payor and/or the payee can set preferences regarding the notifications. Such preferences may include whether the payor wants to receive them at all, whether to selectively receive the notifications based on parameters such as a size of transaction, merchant and/or type of transaction. Another preference regarding the reporting of the notifications may include when and/or at what intervals the notifications are provided to the payor. For example, the notifications may be provided in real time or provided in a batch processing format at some predetermined interval. Another preference regarding the reporting of the notifications may include whether or not indications are provided to the payor when reviewing a transaction history or statement and whether such information is reported in detailed or summary formats.
The two-step attachment/notification may be useful for giving notice to the payee that the payor has made a payment that is substantiated, qualified, conditioned or otherwise modified. The three-step attachment/notification may be useful for giving the payor notice that the payee has accessed the attachment. This may give the payor an opportunity, for example, to timely contact the payee to resolve shipment or billing disputes.
In some embodiments, the intermediary may provide to both the payor and the payee the capability to view, print, save, and/or send an attachment related to a payment.
In some embodiments, the apparatus and methods may be used in connection with Electronic Data Interchange (“EDI ”) platforms and the like. Typically, a financial institution (such as a bank) may receive billpay instructions from a large number of its customers to pay a single payee (such as a credit card company) that is common to all of the payors.
EDI-based transactions enable the financial institution to pay the common payee by transmitting to the payee a single sum of funds along with a list that identifies the payors, the individual payment amounts to be credited to the payors' accounts and any appropriate supporting information. When the common payee receives the sum, it allocates the sum among the payors' accounts.
The invention may provide apparatus and methods by which an individual payor may attach information to a billpay record that will be incorporated into an EDI-based transaction. In some embodiments, billpay attachments from the payors may be transmitted as an electronic “bundle” of attachments. The attachments may be transmitted together with, or separately from, the list of payor identifiers. The financial institution may provide to the payee cross-reference information that links a payor, or a payor account, to a corresponding attachment.
EDI standards were developed by the American National Standards Institute (ANSI) to promote electronic commerce. EDI standards for numerous types of transactions are available. For example, EDI standards are available for purchase orders and invoices. In EDI, all data field names, types, formats, lengths and other data parameters are defined in a data dictionary. EDI platforms may be used by billpay organizations to serve their clients. In the context of the financial services industry, a bank, for example, may be the billpay (or intermediary) organization. A payor may be, for example, a client, customer or account holder of the bank. A payee may be a trading partner of the client. Clients and trading partners may be individuals, organizations, business or government entities. The use of EDI with the invention is set forth in more detail below.
EDI platforms typically communicate at the system-to-system level using structured data. EDI platforms may support the processing of data in any suitable format, such as ANSI X12, CEFACT and EDIFACT. EDI platform data may be translated for interfacing with any suitable accounting systems, such as accounts payable and accounts receivable systems.
In some embodiments of the invention, the apparatus may be used in connection with eCommerce systems. Ecommerce systems operate at different levels. Some are system-to-system. Some are people-to-system. Some are people-to-people. Ecommerce systems may support the use of structured or unstructured data. Ecommerce systems may support the use of data in any suitable format. For example, ecommerce systems may support the use of EDI data, XML data or any other suitable type of data. Ecommerce systems may be part of any suitable commerce system, such as a financial supply chain management system (enterprise resource planning (“ERP”) systems, for example).
Transaction intermediaries using EDI or another platform may process a large volume of payment instructions from a single client. The instructions may be combined into a single electronic file. The payments may be made to domestic payees, foreign payees or both. The payments may include domestic wires, international wires, including Bulk FX wire, or both domestic and foreign wires. The payments may be effected by domestic check or draft, international check or draft. The checks and drafts may be printed in any suitable language.
EDI platforms are compatible with numerous billpay modules, numerous client transmission platforms, and client internal systems. Table 1 shows exemplary EDI-compatible formats in connection with which the apparatus and methods of the invention may be used to attach a data object to an electronic transaction record.
Table 2 shows exemplary EDI-compatible client transmission platforms in connection with which the apparatus and methods of the invention may be used to attach a data object to an electronic transaction record.
Table 3 shows exemplary client internal systems with which the apparatus and methods of the invention may be used.
Apparatus and methods for electronically executing a transaction between a payor and a payee are provided. The apparatus and methods may involve receiving an electronic request from the payor. The request may be a request to transmit funds to the payee. The payor may include a data object in the transaction. The data object may include information that the payor selects. The information may relate to the transaction, terms of the transaction, prior communications between the payor and the payee, prior communications among the payor, the payee and a third party. The data object may be an electronic file, an electronic folder, or any other suitable data structure. The data object may be formatted as an image, text, audio, video or any other suitable format. The apparatus and methods may include establishing an electronic link between the data object and the payee.
Some embodiments of the invention may involve providing access to online billpay information that corresponds to a transaction between a payor and a payee. The apparatus and methods may involve receiving an electronic request from the payor. The request may be a request to transmit funds to the payee. The apparatus and methods may include receiving a data object that the payor has selected for inclusion in the transaction. The data object may be stored in a database. A pointer may be provided. The pointer may point from a stored record of the transaction to the data object. A request for the billpay information may be received from the payor. In response to the request, the billpay information may be provided to the payor.
The apparatus and methods of the invention may be used in connection with any suitable billpay software, such as Fiserv/CheckFree, by any suitable intermediary offering payment services, such as banks, and by any suitable payment networks, such as PayPal®.
In the following description of the various embodiments, reference is made to the accompanying drawings, which form a part hereof, and in which is shown by way of illustration various embodiments in which the invention may be practiced. It is to be understood that other embodiments may be utilized and structural and functional modifications may be made without departing from the scope and spirit of the present invention.
As will be appreciated by one of skill in the art upon reading the following disclosure, various aspects described herein may be embodied as a method, a data processing system, or a computer program product. Accordingly, those aspects may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects.
Furthermore, such aspects may take the form of a computer program product stored by one or more computer-readable storage media having computer-readable program code, or instructions, embodied in or on the storage media. Any suitable computer readable storage media may be utilized, including hard disks, CD-ROMs, optical storage devices, magnetic storage devices, and/or any combination thereof. In addition, various signals representing data or events as described herein may be transferred between a source and a destination in the form of electromagnetic waves traveling through signal-conducting media such as metal wires, optical fibers, and/or wireless transmission media (e.g., air and/or space).
Input/output (“I/O”) module 109 may include a microphone, keypad, touch screen, and/or stylus through which a user of device 101 may provide input, and may also include one or more of a speaker for providing audio output and a video display device for providing textual, audiovisual and/or graphical output. Software may be stored within memory 125 and/or storage to provide instructions to processor 103 for enabling server 101 to perform various functions. For example, memory 125 may store software used by server 101, such as an operating system 117, application programs 119, and an associated database 121. Alternatively, some or all of server 202 computer executable instructions may be embodied in hardware or firmware (not shown). As described in detail below, database 121 may provide storage for account information, account holder information, account application data and statistics, and any other suitable information.
Server 101 may operate in a networked environment supporting connections to one or more remote computers, such as terminals 141 and 151. Terminals 141 and 151 may be personal computers or servers that include many or all of the elements described above relative to server 101. The network connections depicted in
Additionally, application program 119, which may be used by server 101, may include computer executable instructions for invoking user functionality related to communication, such as email, short message service (SMS), and voice input and speech recognition applications.
Computing device 101 and/or terminals 141 or 151 may also be mobile terminals including various other components, such as a battery, speaker, and antennas (not shown).
A client of a financial institution may use a terminal such as 141 or 151 to utilize a billpay platform administered by an intermediary. The client may communicate with the intermediary using a transmission platform such as one of those listed in Table 2. Billpay information, including payee information, payor information, historical transaction records, data objects for attachment, and any other suitable information, may be stored in memory 125. Applications 119 may include a payment origination module such as one of those listed in Table 1.
The invention is operational with numerous other general purpose or special purpose computing system environments or configurations. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, mobile phones and/or other personal digital assistants (“PDAs”), multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
The invention may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
In some embodiments, the document may be attached from a storage medium that is in direct contact with platform/portal 206. For example, the document may be stored in online document storage and storage and retrieval module 208. Online document storage and retrieval module 208 may include any suitable storage media. The storage media may include long term storage media for archiving documents. The storage media may include short term storage media for facilitating storage and retrieval of documents during a limited period of time. Online document storage and retrieval module 208 may include any suitable database engine to file and retrieve documents. Online document storage and retrieval module 208 may include any suitable database server to provide documents to a payor.
Platform/portal 206 may include billpay module 210. Billpay module 210 may include a suitable web server for providing billpay data exchange between platform/portal 206 and workstation 204. Platform/portal 206 may include other modules 212. Other modules 212 may include modules for executing payments. For example, other modules 212 may interface with electronic payment networks 214. Other modules 212 may transmit to electronic payment networks 214 attached documents or linking information regarding the documents in connection with payment information.
Other modules 212 may interface with paper check fulfillment platform 216. Other modules 212 may transmit to paper check fulfillment platform 216 copies of attached documents or copies of linking information regarding the documents in connection with payment information.
Other modules 212 may include modules for storing documents in document archive 218.
Paper check fulfillment platform 216 may print paper check 218. Stub 220 may be attached to check 218 or included in a mailing envelope as a separate sheet with check 218. Stub 220 may include printed information. The printed information may include a unique file code number. The file code number may identify a file that includes transaction information. The transaction information may be stored in platform/portal 206. The transaction information may be stored in document archive 218. The transaction information may include a document that the payer attached to the transaction. The transaction information may include a link to a document that the payer attached to the transaction. The printed information may include instructions for the payee that instruct the payee how to retrieve a copy of the attached document.
Paper check fulfillment platform 216 may include computer-based and/or human-based systems for routing check 216 to postal service 222. Postal service 222 may deliver check 216 to a payee. The payee may use workstation 224 to retrieve an attached document from platform/portal 206. The payee may use workstation 224 to attach a document to a transaction in platform/portal 206.
In process 400, the payor may identify the payee, a payment amount and a payment date. If the payor desires to include an attachment in the payment, the payor may select whether to scan a paper document or attach an electronic document. In some embodiments, the document may be scanned using methods shown and described in co-pending, commonly-assigned U.S. patent application Ser. No. 11/755,543, entitled “Secure Session for Document Scanning”, filed May 30, 2007, which is hereby incorporated herein by reference in its entirety.
The intermediary platform may check to see if the attachment conforms to limits. The limits may be limits of attachment size, content, file type, etc. The intermediary platform may use content-, virus-, or digital rights-, or malware-checking software to check the attachment for inappropriate content or malicious code. The intermediary platform may include a module for testing whether the attachment includes content that is appropriate within the context of the payment.
If the intermediary platform deems the attachment acceptable, the attachment may be archived. The intermediary platform may assign to the attachment a unique file code. The unique file code may be a public key. In some embodiments, if the payee is also a client or customer of the intermediary, the intermediary may grant access rights to the attachment to the payee. The attachment may be logged in an online document storage repository in an account designated for the payor. The repository may correspond to document archive 218 (shown in
The steps of process 400 are now described in more detail. The process may begin at step 402. At step 404, the payor may select a function for paying a bill. At step 406, the payor may enter data specifying a payee, a payment amount and a payment date, as well as optional text/comments. At step 407, if the payor has entered text/comments, process flow may move to step 416 where the system may apply one or more limit or content checking algorithms to the text/comment document. At step 416, algorithms may return positive test results on the text/comments, such as length of comments or unsuitable language content. If step 416 returns a positive result, process flow may continue to step 420 where the payor is notified of the test result. The process flow may then cycle back to step 406 for the payor to re-enter or skip the text/comments. Alternatively, step 416 may automatically redact unsuitable language or truncate the text/comments and continue flow directly to step 408. The text/comments and attachments are not considered mutually exclusive, rather, it is anticipated that complementary text/comments and file attachments may be commonly used by payors in their transactions with payees.
At step 408, the system may inquire of the payor whether there is an attachment.
If the payor does not have an attachment, process 400 may continue at step 410. At step 410, the payor may confirm payment details from preceding steps. Process flow may then switch to payment fulfillment process 500 (shown in
If the payor does have an attachment, process 400 may continue at step 412. At step 412, the system may inquire of the payor whether the attachment will originate from a scan or an electronic file in storage. If the document is to originate from a scan, process 400 continues at step 414. At step 414, the payor may scan a paper document using an appropriate scanning device. Step 414 may include the use of a fax machine to capture the content of the paper document. After step 414, process 400 may continue at step 416. At step 416, the system may apply one or more limit or content checking algorithms to the attached document.
If, at step 412, it is determined that the attachment is to originate from an electronic file, the system may provide the payor with a list of files from which to choose a file to be attached. The payor may select the file to be attached. Files may be resident on a storage medium that is in direct communication with workstation 204 or in online document storage/retrieval module 208 or in document archive 218. Process 400 may then continue at step 416, as described above.
At step 416, if a limit test or a content test has a positive result, the process 400 may continue at step 420. Examples of positive results include: the attachment exceeds a size limit; the attachment includes a virus; the attachment contains digital rights management instructions preventing duplication/distribution; and/or the attachment includes inappropriate subject matter. At step 420, the system may inform the payor of the positive result. Process 400 may then revert to step 408. At step 408, the payor will have an opportunity to attach a different document.
At step 416, if the limit or content tests have only negative results, process 400 may continue at step 420. At step 420, the system may store the attachment in an archive. At step 422, the system may assign a unique file code to the attachment and grant access rights to the payee. When the payee is a client or customer of the intermediary, step 422 may involve provision of a public key to the payee. At step 424, the system may add the attachment to the payor's on-line document storage records. For example, the system may add the attachment to an index of stored documents that are associated with the payor.
Process 400 may end at step 426.
The billpay platform may pay the payee via paper check. The billpay platform may make an electronic payment through a third-party payment network, such as the Automated Clearing House (“ACH”), SWIFT, or any other suitable third-party arrangement. The billpay platform may make payment via entry in a general ledger of an entity to which both the payor and the payee belong (e.g., from one customer to another customer in a closed-loop payment network, such as PayPal®.) The billpay platform may make payment by any other appropriate electronic method.
If an attachment has been attached to the payment, the billpay platform may notify the payee about the attachment. The billpay platform may notify the payee in any suitable manner. For example, if the payment was made by paper check, the billpay platform may provide a printed public-key file code. The billpay platform may provide a uniform resource locator (“URL”) identifying the location of the attachment on the World Wide Web. The billpay platform may also provide instructions regarding accessing the attachment electronically using the public-key file code. The file code and/or the instructions may be printed on a stub or on a separate sheet of paper included in the payment mailing envelope. The stub may be attached to the check. If the payor has provided text/comments as the sole attachment or as a complement to a file attachment, the text/comments may be provided to the payee in the notification, space permitting according to the means of notification. Alternatively, text/comments may be provided to the payee during a two-step or three-step file attachment retrieval process as incorporated herein.
If the payment was made by electronic means, the public-key file code may be included in a payment message that the billpay platform transmits (either electronically, on paper, or both) to the payee. In some embodiments, the payment message (whether on paper or electronic) may include a URL identifying the location of the attachment. If the payment message is electronic, the billpay platform may provide the payee with an electronic link to the attachment. In some embodiments, the payment message may be transmitted by email. In some embodiments, the payment message may be transmitted by short message service (“SMS”). The payment message may be transmitted by any suitable paper or electronic communication. In some embodiments, the text/comments may be provided directly in the electronic payment message to the payee, space permitting according to industry or party standards.
The steps of payment fulfillment process 500 are now described in more detail. Process control may be transferred to payment fulfillment process 500 from step 410 of process 400 (shown in
In some embodiments, the system may include modules for printing the attachment, saving the attachment (e.g., at a workstation such as 204 or 224 (shown in FIG. 2)), or sending the attachment to a location or address, whether physical or electronic. In some embodiments, the system may include a module for authenticating copies of an attachment that originated from the document archive. Authenticated attachments may indicate that the archive is a trusted source.
The steps of attachment retrieval process 600 are now described in more detail. Process control may be transferred to attachment retrieval process 600 from step 508 of process 500 (shown in
At step 608, the system may inquire whether the payor wants to print, save or send a copy of the attachment. If the payor indicates that he does not want to print, save or send the attachment, attachment retrieval process 600 may end at step 610. If the payee indicates that he does want to print, save or send the attachment, attachment retrieval process 600 may continue at step 614. At step 614, the system may query the payee for destination information for printing, saving or sending. The destination information may include, for example, an operating system path, a filename, a printer name, an email address or any other suitable destination information. At step 616, the system may print, save or send the attachment in conformance with the destination information received at step 614. Attachment retrieval process 600 may then end at step 610.
Aspects of the invention have been described in terms of illustrative embodiments thereof. A person having ordinary skill in the art will appreciate that numerous additional embodiments, modifications, and variations may exist that remain within the scope and spirit of the invention.
One of ordinary skill in the art will appreciate that the apparatus features described herein and illustrated in the FIGS. may be arranged in other than the recited configuration and that one or more of the features may be optional. Also, the methods described herein and illustrated in the FIGS. may be performed in other than the recited order and that one or more steps illustrated may be optional. The above-referenced embodiments may involve the use of other additional elements, steps, computer-executable instructions, or computer-readable data structures. In this regard, other embodiments are disclosed herein as well that can be partially or wholly implemented on a computer-readable medium, for example, by storing computer-executable instructions or modules or by utilizing computer-readable data structures.
Thus, systems and methods for attaching information to an online bill payment have been provided. Persons skilled in the art will appreciate that the present invention can be practiced by other than the described embodiments, which are presented for purposes of illustration rather than of limitation, and that the present invention is limited only by the claims that follow.
