Patent Application
20080288397
The invention relates generally to bill payment systems and methods, and more particularly, to a set of bill payment system enhancements for more timely and effective processing of payee-specific remittance information changes associated with managed and/or unmanaged payees.
Reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein:
According to an embodiment of the invention described herein, payee address changes are processed in such a way as to leverage “good” changes as soon and as broadly as possible, thereby minimizing mis-deliveries, late payments, and problem resolution efforts. Embodiments of the invention are described below with reference to block diagrams of systems, methods, apparatuses and computer program products according to an embodiment of the invention. It will be understood that each block of the block diagrams, and combinations of blocks in the block diagrams, respectively, can be implemented by computer program instructions. These computer program instructions may be loaded onto a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions which execute on the computer or other programmable data processing apparatus create means for implementing the functionality of each block of the block diagrams, or combinations of blocks in the block diagrams discussed in detail in the descriptions below.
These computer program instructions may also be stored in a computer-readable memory to together constitute an article of manufacture including instruction means that implement the function specified in the block or blocks. The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions that execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the block or blocks.
Accordingly, blocks of the block diagrams support combinations of means for performing the specified functions, combinations of steps for performing the specified functions and program instruction means for performing the specified functions. It will also be understood that each block of the block diagrams, and combinations of blocks in the block diagrams, can be implemented by special purpose hardware-based computer systems that perform the specified functions or steps, or combinations of special purpose hardware and computer instructions.
The inventions may be implemented through one or more application programs running on one or more operating systems of one or more computers. The inventions also may be practiced with other computer system configurations, including hand-held devices, multiprocessor systems, microprocessor based or programmable consumer electronics, mini-computers, mainframe computers, etc.
Application programs may include software modules, routines, components, objects, data structures, etc. that implement certain abstract data types or perform certain actions or tasks. In a distributed computing environment, the application program (in whole or in part) may be located in local memory, or in other storage. In addition, or in the alternative, the afore-mentioned components that make up the application program (in whole or in part) may be co-resident or distributed (e.g., linked through a communications network) with regard to either storage or execution to allow for the practice of the inventions. Several embodiments of the invention are more fully described hereinafter with reference to the accompanying drawings, in which like numerals indicate like elements throughout the several drawings. Indeed, these inventions may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements.
The payment service provider 102 provides the payment service to one or more subscribers 104. Subscribers 104 communicate with the payment service provider 102 via a network 106. The network 106 may be, for example, the Internet though it could be another public network or even a private network. Further, the network 106 could be multiple networks. For simplicity, only one network is shown in
A subscriber 104, in some instances, communicates directly with the payment service provider 102. In other instances, a subscriber 104 communicates with the payment service provider 102 through one of consumer service providers 108. A consumer service provider 108 is an entity that offers a payment service directly to certain subscribers 104, while the payment service provider 102 provides some supporting functionality, i.e., payment processing and remittance issuance, of completing payments. A consumer service provider 108 may also be referred to as a sponsor. A consumer service provider 108 may present a payment service user interface to a subscriber 104 to provide information to, and receive information from, a subscriber 104. Such a consumer service provider 108 receives information from the payment service provider 102, via the network 106, and then presents such information to a subscriber 104. Likewise in such instances, a consumer service provider 108 receives information from a subscriber 104, and then passes such to the payment service provider 102 via the network 106. Communications between a subscriber 104 and a consumer service provider 108 can, as desired, be via the network 106, via another network, or otherwise. In other situations in which a consumer service provider 108 offers payment services, the payment service provider 102 provides a payment service user interface (UI) directly to a subscriber 104, via the network 106, that is branded as belonging to a consumer service provider 108. It is also possible that, at least for some subset of subscribers 104, the payment service provider 102 fully encompasses the role of consumer service provider (i.e., not only presents the UI, but the contractual relationship with the subscriber is with the service provider and the UI is branded as belonging to the service provider.)
The remittance information for a managed payee may include one or more account schemes and/or account formats utilized for Accounts Receivable posting at the managed payee 112, account number ranges used for remittance center identification, other information useful for remittance center identification, preferred credit form (paper or electronic), preferred remittance advice form (paper or electronic), a deposit account to which payments may be electronically credited, electronic links for delivery of electronic credits and/or electronic remittance advice (described below), and/or any other information useful in the remittance processing associated with a particular payee. A managed payee 112 provides remittance information to the payment service provider 102. The received remittance information is typically stored in a managed payee database (also referred to as a managed merchant database). An electronic payee is a managed payee about whom a payment service provider maintains information enabling remittance to be issued electronically. A merchant is a payee that issues bills for services rendered or goods purchased. A merchant can be an unmanaged merchant a managed merchant, or an electronic merchant.
Remittance advice is a description of a credit that allows proper payment posting to a specific account, or sub-account, in a payee's Accounts Receivable ledger. Remittance advice may be coupled with an instrument used to accomplish the credit (e.g., information printed in a memo field on a check or draft, or information included in a field in an electronic funds transfer file transmitted over a network linking financial institutions). Alternatively, remittance advice may be somewhat decoupled from the credit, such as a paper document delivered to a payee separate from the delivery of a credit, or an electronic file transmitted directly to the payee separate from the delivery of the credit. Remittance advice may include information identifying a payor, information identifying the payor's account with the payee, a payment account, and/or other information useful to describing a credit for proper payment processing.
Also shown in
Also shown in
The data repository 208 includes a managed payee database 212 that stores information identifying and associated with managed payees. A managed payee database 212 includes information identifying each managed payee known to a payment service provider, along with the information received from each managed payee. In an example embodiment of the invention the data repository 208 may also include an unmanaged payee database. Several embodiments of the invention may create and/or maintain a database of “normalized” or “authoritative” information associated with unmanaged payees. Such a database allows changes deemed “authoritative” to be picked up for all subscribers associated with the payee. The creation and function of the unmanaged payee database will be described in further detail below with reference to
The data repository 208 also includes a subscriber database 214 that stores information identifying and associated with subscribers. The subscriber database 214 may include, for each subscriber, a subscriber's name, address, funding account information, profile information, payee lists, bills, pending and/or historical payments and/or other data associated with a particular subscriber. In one embodiment of the invention, the subscriber database 214 may also include a subscriber's phone number and e-mail address. Also, as desired, the subscriber database 214 may include other types of information associated with a subscriber. Other information utilized in payment processing may also be stored in the data repository 208.
Next, step 404 is invoked to check whether there are subscribers remaining to process. If there are no additional subscribers to process, the creation of the unmanaged payee database is complete and processing ends. If there are additional subscribers to process, processing of the “Ith” subscriber's payee list continues with step 408.
In step 408, an iteration limit “J” is set to the number of payees in the “Ith” subscriber's payee list. Next, step 410 is invoked to check whether there are remaining payees to process. If there are no remaining payees to process, processing of the “Ith” subscriber's payee list is complete and processing continues with step 406, in which the counter, I, is decremented. Then control returns to step 404 to determine if there are any more subscribers to process.
If there are additional payees to process, then step 412 is invoked to check whether the “Jth” payee in the payee list is an unmanaged payee. This determination may include verifying a managed/unmanaged indicator in the payee list entry, looking for a link to a managed merchant database entry, or, at the other end of the spectrum, it may involve attempting merchant identification anew based on current contents of the “Jth” payee list entry. If the “Jth” payee is determined to be a managed payee, further processing of that entry is skipped, and step 424 is invoked in which “J” is decremented in and control returns to step 410 to determine if there are additional payee list entries to process.
If it is determined that the “Jth” payee is unmanaged in step 412, then step 414 is invoked in which a set of values from the “Jth” payee list entry is sent to a third party identity service. The values sent to the third party identity service may include one or more of payee name, payee address, payee telephone number, payee tax identifier, payee email ID, or other available information associated with a payee. The third party identity service is a commercial service that attempts to match the supplied information to an entity in its comprehensive data repository. If the service finds a match, it returns either a definitive universal identifier (UID) or a temporary identifier (TID), either of which is unique across all entities. In addition, the service also returns a “best-known” address for the entity, which may differ from that supplied. It is possible that the service cannot find a match and is unable to return either an LID or TID.
Step 416 determines whether an UID or TID with a “best-known” address was received from the third party identity service. If an LID or TID with a “best-known” address was not received, nothing further can be done with the current unmanaged payee (i.e., it cannot be added in an authoritative manner to the unmanaged payee database, or matched against an existing entry). Thus, step 424 is invoked where counter “J” is decremented, and control returns to step 410 to determine if there are additional payee list entries to process. Ultimately the unmanaged payee database will contain all unmanaged payees. In an alternative embodiment of the invention, if no UID or TID is received from the third party identity service a value corresponding to an UID or TID could be locally created and assigned to the unmanaged payee instead of skipping to the next unmanaged payee. Most, if not all, entries will contain an UID or TID returned from the third party identity service, though some entries may contain a locally created equivalent to the UID or TID. The algorithm for creating such a local value may ensure that there would be no conflict with historic or future values received from the third party identity service. This could be achieved by, for instance, using a prefix that the third party identity service would not use, or alternatively, locating a prefix in character positions that extend the field length beyond that of the value returned by the identity service.
For example, if the identity service returns a 12-character numeric string, the field could be extended to 13 characters, with a leading “0” if an UID or TID from the third party identity service is used and some alternate character if a value is locally created. In addition, the algorithm for creating a local value should not be such that the same unmanaged payee in two different payee lists could produce the same value. In an alternative embodiment of the invention, the payee information and the locally assigned values may be provided to the third party identity service, so that the third party identity service's existing matching algorithms may be leveraged to match against these values as well. Additional local value creation techniques may be appreciable by one of ordinary skill in the art. Once a value is locally created and assigned, processing can continue with step 418.
If an UID or TID with a “best-known” address was received in step 416 or a value was locally created and assigned, then step 418 is invoked to determine whether the UID or TID already exists on the unmanaged payee database (e.g., as a result of processing another subscriber's payee list). If the UID or TID already exists on the unmanaged payee database, then step 422 is invoked, where a cross-reference link is added to the current “Jth” payee list entry and possibly also to the entry found in the unmanaged payee database.
If the UID or TID does not already exists on the unmanaged payee database, then step 420 is invoked to create a new entry in the unmanaged payee database This entry would contain at least the UID or TID and the “best-known” address received from the third party identity service. In one embodiment of the invention, the address received from the third party identity service is treated as better than any historical data in payee list entries. In an alternative embodiment of the invention, it may be possible to determine when the payee address in the “Jth” payee list entry was last modified, and if that is more recent than a predetermined time period (e.g., a number of days since the last modification), the address may be considered more current for use in remittance processing. Step 422 is then invoked, in which the UJID or TID is added to the “Jth” payee list entry. This allows the service provider to pick up the “authoritative” information from the unmanaged payee database when processing a payment request to this unmanaged payee.
However, the subscriber-supplied information in the payee list entry is neither replaced nor deleted. In addition, the “Ith” subscriber identifier may be added to a list of subscribers associated with the unmanaged payee in the UID or TID entry just found or created. This facilitates quick determination of how many, and which, subscribers have identified this unmanaged payee as a payee. Step 422 may not be completely optional, as this is also where the UID or TID is added into the “Jth” payee list entry.) Next, step 424 is invoked where “J” is decremented and control returns to step 410 to determine if there are additional payee list entries to process. If there are no additional payee list entries to process, then the unmanaged payee database creation process is completed.
Next in step 504, for an “add payee” transaction, a new payee list entry for the new payee is created in the subscriber's payee list, capturing the provided information (payee name, payee address, etc.). Alternatively, in step 504, for a “change payee” transaction, an existing payee list entry in the subscriber's payee list is updated with the provided information.
Step 506 is then invoked to determine if the payee is a managed payee. This determination may include verifying a managed/unmanaged indicator in the payee list entry, looking for a link to a managed merchant database entry, or, at the other end of the spectrum, it may involve attempting merchant identification anew based on current contents of the payee list entry. There are a number of ways that merchant identification could be done, such as running the received address data through an acquired software utility (e.g., Code One from Group One, Inc.) to generate a 9- or 11-digit zip code, then use this extended zip code to locate a match on the managed payee database. If the payee is a managed payee, step 508 is invoked to begin the process of updating the managed payee database as described in
If, in step 506, it was determined that the payee is not a managed payee, then step 510 is invoked to determine whether the payee list entry contains an UID or TID. If one of these values is found, it may be used as a link to an entry on the unmanaged payee database, and processing continues with step 512, in which the process of updating the unmanaged payee database described in
If no UID or TID was found in step 510, then the unmanaged payee has not yet been successfully entered or matched to the unmanaged payee database, and step 514 is invoked, in which the process of adding the unmanaged payee to the unmanaged payee database described in
The process shown in
In the case of a managed payee relationship, the managed payee may proactively provide notification of an address change. There are several options as to how this could be processed. First, the address change from the managed payee may be treated as authoritative and accepted without question, automatically replacing the address in the appropriate managed payee database entry. Second, the address change may be treated as equivalent to a subscriber-supplied payee address modification for a “high volume” merchant, and may cause the processing for substituting the received address for the payee list address, shown in
Referring back to the embodiment of
If the managed payee is not a “high volume” merchant, then step 606 is invoked, in which the new address is saved in a list of addresses that have been received and considered for this payee and is sent to the account manager for that merchant. The account manager performs research to determine whether the new address should be adopted or not. Step 618 is then invoked to determine whether the account manager approves the change or not. If the account manager has not approved the changes, the processing of a subscriber-supplied managed payee address that does not match the previously known address stored in the matching managed payee database entry terminates. If the change is approved by the account manager, then step 616 is invoked, in which the address currently in the managed payee database is replaced with the new address (potentially normalized) that had been received from the subscriber. At this point the processing of a subscriber-supplied managed payee address that does not match the previously known address stored in the matching managed payee database entry terminates.
If it was determined that the managed payee is not a “high volume” merchant in step 602, then step 604 is invoked to determine whether the newly received payee address matches any address previously received from another subscriber that has been stored in association with the managed payee database entry. Again, this match may require normalization of data and/or matching on the basis of an extended zip code. If the current address is not found, step 608 is invoked, in which the current address is stored in association with the current managed payee database entry, and a new counter associated with this “pending” address is created and set to 1. At this point the processing of a subscriber-supplied managed payee address that does not match the previously known address stored in the matching managed payee database entry terminates.
If the current payee address was found to match one of the addresses stored, then step 610 is invoked to determine whether the counter associated with the pending address, incremented by 1 to include the current subscriber's citation of this address, is greater than or equal to some threshold value (N). If the sum of the previous counter value+1 is still less than the threshold value, the step 612 is invoked, in which the counter is incremented. At this point the processing of a subscriber-supplied managed payee address that does not match the previously known address stored in the matching managed payee database entry terminates.
If the sum of the previous counter value+1 is greater than or equal to the threshold value, then there have been enough citations of this address to cause it to be adopted as the new authoritative payee address, and step 614 is invoked. Other methods of tracking the number of subscriber submissions of a particular address associated with a particular payee may be appreciable by one of ordinary skill in that art. In step 614, the pending address and its associated counter are deleted. Next, step 616 is invoked, in which the managed payee database entry is updated with the new payee list address (potentially normalized). At this point the processing of a subscriber-supplied managed payee address that does not match the previously known address stored in the matching managed payee database entry terminates. In an alternative embodiment of the invention, the processing described above for “high volume” merchants may be performed for those merchants that are not “high volume,” and/or the processing described above for merchants that are not “high volume” may be performed for “high volume” merchants.
Step 701 is invoked to determine whether the address supplied by the subscriber (in the just-created payee list entry) matches the currently authoritative address in the unmanaged payee database entry. Because subscriber-supplied address information for the same entity may vary widely in format or content, some normalization of data and/or generation of a database lookup key may be required before the process can definitively determine whether the subscriber-supplied address matches the unmanaged payee database entry. This might, for instance, require the generation of a 9 or 11-digit zip code through a utility like Code One and a comparison on the basis of the extended zip codes. Code One is a software product from Group One, Inc. that generates an 11-digit zip code from supplied address information. If the two addresses are determined to match, this further processing ends. If the two addresses are determined to be different, processing continues with step 702.
Step 702 determines whether the newly received payee address matches any address previously received from another subscriber that has been stored in association with an unmanaged payee database entry for further consideration. This match may require normalization of data and/or matching on the basis of an extended zip code, as described earlier. If the current address is not found, processing continues with step 704, in which the current address is stored in association with the current unmanaged payee database entry, and a new counter associated with this “pending” address is created and set to 1. At that point the processing of a subscriber-supplied unmanaged payee address that does not match the “best-known” address in the matching unmanaged payee database entry ends.
If a match for the newly received payee address was found among the “pending” addresses associated with the unmanaged payee database entry, then step 706 is invoked to determine whether the counter associated with the matched pending address, which is (or has previously been) incremented by 1 to include the current subscriber's citation of this address, is greater than or equal to a threshold value (T). This threshold is not necessarily the same as the previously described threshold value. If the counter value, which reflects the current subscriber citation of the address (e.g., previous counter value+1), is still less than the threshold value, then step 708 is invoked where the counter is incremented. At that point the processing of a subscriber-supplied unmanaged payee address that does not match the “best-known” address in the matching unmanaged payee database entry ends.
If the sum of the previous counter value+1 is equal to or greater than the threshold value, then there have been enough citations of this address to cause it to be adopted as the new authoritative payee address, and step 710 is invoked where the stored pending address and its associated counter are deleted and the unmanaged payee database entry is updated with the new address. At that point the processing of a subscriber-supplied unmanaged payee address that does not match the “best-known” address in the corresponding unmanaged payee database entry ends. Note that while the address in the unmanaged payee database entry is updated, and the payer's payee list entry points to this, the address in the payee list entry may not be updated.
In an alternative embodiment to the process shown in
Next, step 804 is invoked to determine whether an UID or TID (along with a “best-known” address) was received from the third party identity service. If not, nothing further can be done with the current unmanaged payee (i.e., it cannot be added in an authoritative manner to the unmanaged payee database, or matched against an existing entry), and processing ends. If a UID or TID was received from a third party service, then processing of the current payee (an unmanaged payee for which an UID or TID and “best known” address has been received) continues with step 806.
Most, if not all, unmanaged payee database entries will contain an UID or TID returned from the third party identity service. However, some entries may contain a locally created equivalent to the UID or TID. For instance, in an alternative embodiment of the invention not shown in the flow diagram of
For example, if the identity service returns a 12-character numeric string, the field could be extended to 13 characters, with a leading 0 if an UID or TID from the identity service is used and some alternate character if a value is locally created. In one embodiment of the invention, the algorithm for creating a local value should not be completely random because the same unmanaged payee in two different payee lists may produce the same value. In another embodiment of the invention, the payee information with the locally assigned values to the third party identity service so that third party identity service's existing sophisticated matching algorithm can be leveraged to match against these values. Additional local value creation techniques may be appreciable by one of ordinary skill in the art.
A locally created UJID or TID value should be replaced with a “real” UID or TID if one is returned later when another subscriber adds the same payee. Such functionality may require that when a “real” UID or TID is returned, the process to create a local value is also executed, where an attempt is made to find a match of the local value on the unmanaged payee database. If a match is found, then the data returned from the identity service (UID or TID and “best known” address) can replace prior values on the database.
Once a value is locally created and assigned, processing can continue with step 806. Step 806 determines whether the UID or TID already exists on the unmanaged payee database. If the UID or TID is not found on the unmanaged payee database, then step 808 is invoked where a new entry is created in the unmanaged payee database. This entry would include the UID or TID.
If the UID or TID is found on the unmanaged payee database, then step 810 is invoked, in which the “best-known” address in the matching entry on the unmanaged payee database is updated. The “best-known” address just received from the third party identity service updates a missing or different address in the unmanaged payee database entry as necessary and appropriate. If, as a result of the processing of the new unmanaged payee address (discussed in detail with reference to
Once the address in the unmanaged payee database has been updated or added, then step 812 is invoked, where the UID or TID is added to the payee list entry. In one embodiment of the invention, this may support obtaining the “authoritative” information from the unmanaged payee database when processing a payment request directed towards this particular unmanaged payee. In another embodiment of the invention, the subscriber-supplied information in the payee list entry is neither replaced nor deleted. In an alternative embodiment of the invention, the subscriber identifier could be added to a list of subscribers associated with the unmanaged payee in the UID or TID entry just updated or created. Such cross-reference may facilitate quick determination of how many, and which, subscribers have identified this unmanaged payee as a payee. Another way to determine this information would be to search all payee lists for a particular UID or TID.
After step 812 is completed, step 814 determines whether the payee address in the payee list entry matches the “best-known” address present in the unmanaged payee database entry. If the addresses match, then the process ends. If the addresses do not match, then step 816 is invoked where the new unmanaged payee address is processed, which is discussed in detail with reference to
For changes to existing payee list entries, the third party identity service may provide proactive notification of a change in the “best-known” address for a payee, assuming the identity service retains knowledge of UIDs previously sent to us. The address change would be received with the UID or TID, so it would be quite straightforward to look up the entry on the unmanaged payee database. Assuming the corresponding entry is found (i.e., it is possible that the unmanaged payee could become a managed payee and be removed from the unmanaged payee database), there are at least two options for processing the address change. First, the address change from the third party identity service may be treated as authoritative and accepted without question, replacing the existing “best-known” address in the unmanaged payee database entry. Second, the address change from the third party identity service may be treated as no more authoritative than a subscriber-supplied payee address modification, and processing of substituting the received address for the payee list address would be executed.
Next, in step 904, the code is used to access the correct payment in the payment history table and from there determine the set of subscribers associated with the payment, and the payee list entry corresponding to the payee for each subscriber in the list. Step 906 is then invoked to set an iteration limit (I) to the number of subscribers identified in step 904. Then a processing loop is executed for each subscriber between steps 908 and 922. Step 908 determines if the counter is greater than zero indicating there are additional subscribers to process. If the counter is at zero, then processing ends.
If the counter is higher than zero, then step 910 is invoked where the “Ith” subscriber's payee list entry is updated with the address received from the USPS. Such functionality reflects an assumption that if the subscriber had sent the payment herself and received an address correction from the USPS, she would have taken notice of it for future payments, and thus the automated processing should perform the same on behalf of the subscriber. Alternatively, a slight variant of the subsequent processing could be performed without updating the payee list entry, thus using the USPS-received payee address instead of the payee list entry address.
Then processing continues with step 912 to determine if the payee is a managed payee. In one embodiment of the invention, the determination of step 912 may be as simple as verifying a managed/unmanaged indicator in the payee list entry, looking for a link to a managed merchant database entry, or, at the other end of the spectrum, it could involve attempting merchant identification anew based on current contents of the payee list entry. If the payee is a managed payee, the step 914 is invoked to begin the process of updating of the managed payee database as described in
If, in step 912, it was determined that the payee is not a managed payee, then step 916 is invoked to determine whether the payee list entry contains an UID or TIP. If one of these values is present, it is a link to an entry on the unmanaged payee database, and processing continues with step 918, in which the process of updating the unmanaged payee database described above with reference to
If no UID or TID was found in step 916, then this is an unmanaged payee that has not yet been successfully entered on (or matched to) the unmanaged payee database, and step 920 is invoked, in which the process of adding the unmanaged payee described above with reference to
Many modifications and other embodiments of the inventions set forth herein will come to mind to one skilled in the art to which these inventions pertain having the benefit of the teachings presented in the foregoing descriptions and the associated drawings. Therefore, it is to be understood that the inventions are not to be limited to the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.
