Sign up to receive free email alerts when patent applications with chosen keywords are publishedSIGN UP

Abstract:

A technique is provided that transforms account number data received from
the consumer into one or more forms based on use by specific processes.
Further provided is a technique for establishing payees using these
account numbers such that remittances can be routed via the most cost
effective means, e.g. which remittance processor is determined and/or
which processor among internal processors within an enterprise is
determined, and such that, when available, electronic bills can be
successfully requested for on-line presentation. The technique to
transform account number data can be applied by systems in industries
other than banking and for account numbers from sources other than a
customer.

Claims:

1. A computer implemented method for transforming account number data
received from a source into one or more forms based on use by specific
post-processes, comprising the steps of: receiving an account number from
a source and receiving an indicated post-processing purpose; if
available, applying a set of cleansing instructions, said instructions
based on said indicated post-processing purpose, to said account number
to output one or more cleansed account numbers; if one or more outputted
cleansed account numbers are available, using said one or more cleansed
account numbers in intermediate processing; if said one or more cleansed
account numbers pass said intermediate processing, then using said passed
and cleansed account number for post-processing; otherwise, trimming said
received account number and using said trimmed account number in said
intermediate processing; and if said trimmed account number passes said
intermediate processing, then using said trimmed number for
post-processing, otherwise, invoking an appropriate error handling
process.

2. The computer implemented method of claim 1, wherein said source is a
customer, said intermediate processing is mask testing, and said
post-processing comprises payee creation for the purposes of payment
remittance and, optionally, eBill activation and presentment.

3. The computer implemented method of claim 2, further comprising the
step of: determining said set of instructions based on type of payee.

5. The computer implemented method of claim 2, further comprising the
step of: using either said cleansed or trimmed account number to
determine an optimal route for remittances.

6. The computer implemented method of claim 1, wherein said set of
cleansing instructions comprises any combination of the following
operations: changing the case of the characters to either upper or lower
case; using the syntax of a regular expression, as follows: to define the
set of valid characters; all others are removed; or to describe the
elements of an account number that the system searches for and extracts,
that is discarding all other input, as well as how to reassemble and
format the resulting elements into an account number; and adding
characters, as follows: specifying a character to pad with, including
padding to the right or padding to the left, and specifying the target
length of the resulting account number; or specifying a set of characters
and whether to use as a prefix or suffix.

7. The computer implemented method of claim 2, further comprising the
step of: using as input that which the customer entered and using said
input as a flexible string variable and associating said string to a
merchant in a list of merchants for electronic remittances.

8. The computer implemented method of claim 2, further comprising the
step of: moving a payee to another payment processor without customer
intervention.

9. The computer implemented method of claim 2, further comprising the
step of: providing a tool for an administrator that manages merchant
information of merchants in a pick list, said information comprising:
addresses; account masks; and multiple payment processors.

10. A system for transforming account number data received from a source
into one or more forms based on use by specific post-processes,
comprising: means for receiving an account number from a source and
receiving an indicated post-processing purpose; if available, means for
applying a set of cleansing instructions, said instructions based on said
indicated post-processing purpose, to said account number to output one
or more cleansed account numbers; if one or more outputted cleansed
account numbers are available, means for using said one or more cleansed
account numbers in intermediate processing; if said one or more cleansed
account numbers pass said intermediate processing, then means for using
said passed and cleansed account number for post-processing; otherwise,
means for trimming said received account number and means for using said
trimmed account number in said intermediate processing; and if said
trimmed account number passes said intermediate processing, then means
for using said trimmed number for post-processing, otherwise, means for
invoking an appropriate error handling process.

11. The system of claim 10, wherein said source is a customer, said
intermediate processing is mask testing, and said post-processing
comprises payee creation for the purposes of payment remittance and,
optionally, eBill activation and presentment.

12. The system of claim 11, further comprising: means for determining
said set of instructions based on type of payee.

14. The system of claim 11, further comprising: means for using either
said cleansed or trimmed account number to determine an optimal route for
remittances.

15. The system of claim 10, wherein said set of cleansing instructions
comprises any combination of the following operations: changing the case
of the characters to either upper or lower case; using the syntax of a
regular expression, as follows: to define the set of valid characters;
all others are removed; or to describe the elements of an account number
that the system searches for and extracts, that is discarding all other
input, as well as how to reassemble and format the resulting elements
into an account number; and adding characters, as follows: specifying a
character to pad with, including padding to the right or padding to the
left, and specifying the target length of the resulting account number;
or specifying a set of characters and whether to use as a prefix or
suffix.

16. The system of claim 11, further comprising: means for using as input
that which the customer entered and means for using said input as a
flexible string variable and associating said string to a merchant in a
list of merchants for electronic remittances.

17. The system of claim 11, further comprising: means for moving a payee
to another payment processor without customer intervention.

18. The system of claim 11, further comprising: a tool for an
administrator that manages merchant information of merchants in a pick
list, said information comprising: addresses; account masks; and multiple
payment processors.

19.-20. (canceled)

Description:

CROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Patent
Application Ser. No. 60/648,218, filed on Jan. 28, 2005, Attorney Docket
Number WELL0052PR, which application is incorporated herein in its
entirety by the reference thereto.

BACKGROUND OF THE INVENTION

[0002] 1. Technical Field

[0003] The invention relates to electronic payment over the Internet. More
particularly, the invention relates to a system and method for enhancing
bill payment and presentment services over the Internet by using a novel
account number processing system and method.

[0004] 2. Description of the Prior Art

[0005] Presently, some enterprises offer a combined electronic bill
presentment (eBill) and payment service over the Internet. For example,
Wells Fargo has a bill payment product and service system, referred to as
Wells Fargo's Bill Pay, which can present bills from particular Merchants
as well as send payments, i.e. remittances, to any Merchant or
individual. The availability of an electronic bill is dependent on the
pass/fail of the Customer's entered account number matched against the
Merchant provided account masks. Which method of remittance and which
route for a remittance are also determined by the pass/fail of the
Customer's entered account number matched against the Merchant provided
account masks. Along with the account activation, the Customer's screen
navigation flow is also dependent on the pass/fail of account mask tests.

[0006] The account masks provided by a Merchant for eBills and remittances
are not always the same. This can occur for example when a Merchant uses
multiple accounting systems and not all account statements and bills are
available electronically but the Merchant can receive remittances for all
accounts. Merchants provide updated account masks to Wells Fargo on a
daily basis.

[0007] Bill Pay was experiencing a high rate of account mask failures when
Customers were adding Payees to send remittances to and/or attempting to
activate eBills. Preliminary research indicates that the issues are
primarily the result of how Customers are entering their account numbers
when adding Payees. Apparently, Customers are not following the
instructions that appear on Add Payee screens when adding account
information, specifically the account number, leading to the high level
of eBill activation rejections and remittances routed less than
optimally.

[0008] Some systems attempt to solve similar problems. For example, D. L.
Garrison, P. A. Kight, B. Perkins, C. L. Ward, M. E. Lawson, and A. L.
Kerin, Electronic Bill Payment System with Account-Number Scheming, U.S.
Pat. No. 6,327,577 B1 (Dec. 4, 2001) teaches a technique for validating a
submitted consumer's account number; a technique that tries to ensure
that consumer payments are remitted to the proper one of multiple
remittance centers associated with the same; and a technique that
transforms payment data received from the consumer into a form compatible
with a merchant's accounting system.

[0009] G. A. Kramer and J. C. Weber, Settlement of Aggregated Electronic
Transactions Over a Network, U.S. Pat. No. 6,324,525 B1 (Nov. 27, 2001
teaches one technique by which messages flow over the Internet directly
from a merchant to card issuers, thereby bypassing the merchant's
acquirer altogether and another technique. Another method is taught for
consummating a series of electronic transactions between a first
electronic device, such as an acquirer device, and a second electronic
device, such as an issuer device, and a plurality of electronic
terminals, such as a plurality of merchant terminals of different
merchants, includes establishing a communication between the plurality of
devices and terminals and accumulating transactions that are approved by
the second electronic device. Then, periodically the series of
transactions are settled using a transfer of monetary value between the
first electronic device and the second electronic device.

[0010] D. W. Kravitz, Payment and Transactions in Electronic Commerce
System, U.S. Pat. No. 6,029,150 (Feb. 22, 2000) teaches a method of
payment in an electronic commerce system wherein customers have accounts
with an agent and where each customer shares a respective secret between
that customer and the agent. This secret is set up prior to the actual
transaction or payment and, in preferred embodiments, is a dynamic
secret. Kravitz states that a problem with payment systems that make an
instantaneous payment to merchants is that if a fraudulent merchant is
accepting many fraudulent transactions, he might not be detected until he
had already received much money and that it is desirable to provide a
payment system that is non-appealable, does not need extensive records,
is relatively anonymous for the consumer, and adequately deals with
micropayments to individual merchants.

[0011] Also, W. R. McMichael and C. W. Kozee, A Reduced Communication
Technique for Matching Electronic Billers and Consumers, European Patent
Application No. EP 1 463 012 A2 (Sep. 29, 2004) discusses a technique for
identifying an association between a consumer and an electronic biller. A
biller transmits customer demographic data to an identity service. The
identity service generates a first entity identifier based upon the
received customer demographic data. The first entity identifier does not
reveal any customer demographic information. The identity service
transmits the generated first entity identifier and a biller identifier
to an electronic bill presentment service. The presentment service
transmits consumer demographic to the identity service. The identity
service generates a second entity identifier based upon the received
consumer demographic data and transmits the generated second entity
identifier to the presentment service. The second entity identifier does
not reveal any consumer demographic information. After receipt of the
first and second entity identifiers and the biller identifier, the
presentment service identifies an association between the consumer and
the biller and transmits a notice of the association.

[0012] However, none of the prior art provides a technique that solves the
problems solved by the invention described herein. None of the prior art
solves the problem of electronic payment system account number rejections
in the manner of the claimed invention.

[0013] In view of the discussion hereinabove, it therefore would be
advantageous and desirable to provide: [0014] a unique combination of
selectable account cleansing, also referred to herein as account
handling, capabilities; [0015] the ability to specify different sets of
account cleansing capabilities based on the targeted Merchant and the
intended use of the payee, i.e. for remittance processing or for combined
remittance processing and electronic bill presentment; [0016] the ability
to use the account cleansing capabilities to transform account number
data received from the consumer into multiple forms of an account number
for use by specific processes, i.e. display, mask matching, remittances,
and electronic bill presentment; [0017] a global trim rule to handle
leading and trailing spaces for all customer entered account numbers;
[0018] a new second pass of account mask routines if the system cleansed
account numbers do not pass the applicable account masks; [0019] a screen
navigation change to allow for Customer re-try of an account number that
fails a Merchant account mask; [0020] a screen content change to assist
users when re-entering account numbers after an account mask failure; and
[0021] a report to assist the Bill Pay administrators in the creation and
maintenance of the account cleansing rules.

[0022] It further would be advantageous to provide a technique for
enhancing or improving routing capabilities between multiple payment
processors.

[0023] It further would be advantageous to provide a Scrub and Match
process that extends the account number handling method and an Automated
Redirections process that improves routing efficiency.

[0024] It further would be advantageous to provide a system and method
that accepts as input that which the customer entered and, having
incorporated the customer input into a token, such as a flexible string
variable, associates the token with one of the merchants in a list of
merchants. This functionality is referred to herein as Scrub & Match.

[0025] It further would be advantageous to provide a system and method
that allows an administrator of a bill pay system to change the processor
payee that the enterprise's customer's payees are associated with, which
results in changing how payment remittances are routed and is referred to
herein as Auto Redirections.

SUMMARY OF THE INVENTION

[0026] A technique is provided that transforms account number data
received from the consumer into one or more forms based on use by
specific processes. Further provided is a technique for establishing
payees using these account numbers such that remittances can be routed
via the most cost effective means, e.g. which remittance processor is
determined and/or which processor among internal processors within an
enterprise is determined, and such that, when available, electronic bills
can be successfully requested for on-line presentation. The technique to
transform account number data can be applied by systems in industries
other than banking and for account numbers from sources other than a
customer.

BRIEF DESCRIPTION OF THE DRAWINGS

[0027] FIG. 1 is a schematic flow diagram of first and second pass
functionality 100 according to the invention;

[0028] FIG. 2a is a continuation of the flow diagram of FIG. 1 for a
restricted and unrestricted merchant path according to the invention;

[0029]FIG. 2B is a continuation of the flow diagram of FIG. 2a for a
restricted merchant path according to the invention;

[0030]FIG. 3 is a continuation of the flow diagram of FIG. 2a for an
unrestricted merchant path according to the invention;

[0031] FIG. 4 is a screen print of an Account Info for eBill (consumer)
screen according to the invention;

[0032]FIG. 5 is a screen print of an Account Info for eBill (business)
screen according to the invention;

[0033] FIG. 6 is a screen print of a Payment Options for Online Bill
(manual option) screen according to the invention;

[0034] FIG. 7 is a screen print of a Account Not Eligible for ebill screen
according to the invention;

[0035] FIG. 8 is a screen print of an Edit Payee screen according to the
invention;

[0036] FIG. 9 is a screen print of a Payee Management screen according to
the invention;

[0037] FIG. 10 is a screen print of an Account Number Not Valid screen
according to the invention;

[0038] FIG. 11 is a screen print of a Search & Browse Payee screen
according to the invention; and

[0039] FIG. 12 is a flow diagram for payee creation and eBill activation
according to the invention.

DETAILED DESCRIPTION OF THE INVENTION

[0040] A technique is provided that transforms account number data
received from the consumer into one or more forms based on use by
specific processes. Further provided is a technique for establishing
payees using these account numbers such that remittances can be routed
via the most cost effective means, e.g. which remittance processor is
determined and/or which processor among internal processors within an
enterprise is determined, and such that, when available, electronic bills
can be successfully requested for on-line presentation. The technique to
transform account number data can be applied by systems in industries
other than banking and for account numbers from sources other than a
customer.

[0041] It should be appreciated that account handling and account
cleansing have the same meaning herein and are used herein
interchangeably.

[0042] In one embodiment of the invention, for each Merchant, the system
and method provides the ability to enter and store two sets of account
number cleansing instructions, described in detail hereinbelow under the
section, Account Number Cleansing Methods. One set is intended for use
when customers are remitting money to a merchant and not requesting to
receive eBills from this merchant. The other set is used when electronic
bills presentment (eBills) is available from this merchant and the
customer elects to both remit money to and requests to receive eBills
from this merchant. Electronic bills presentment is a service provided
jointly by the Merchant and by the enterprise, where the Merchant can
send billing data electronically to the enterprise to provide, e.g.
display, to the customer. In the first pass when no cleansing
instructions are provided or in the second pass after the cleansed
account number fails the account masks in the first pass, leading and
trailing spaces are trimmed from the account number as entered by the
customer and that form of the account number is used for all subsequent
processing.

[0043] The first set of cleansing instructions, used when customers are
only remitting money to the merchant, consists of three account cleansing
instructions, each producing its own form of the account number. The
resulting three forms of the account number may or may not be the same.
The first form is used to display the account number back to the
customer. The second form is used to match to the merchant supplied masks
and to determine to which processor the remittances are routed. The third
form associated with the remittances sent to the merchant and is embedded
in the remittance itself.

[0044] The second set of cleansing instructions, used when the customer
elects both to remit money to and to receive eBills from this merchant,
consists of four account cleansing instructions, each producing its own
form of the account number. The resulting four forms of the account
number may or may not be the same. The first form is used to display the
account number back to the customer. The second form is used to try to
match the merchant supplied masks and to determine how remittances are
routed. The third form is associated with the remittances sent to the
merchant and can be embedded in such remittances. The fourth form is used
to request the merchant to start to produce and send an electronic form
of the customer's bill for presentation, a process referred to herein as
account activation.

[0045] Employing these account cleansing mechanisms improves the match
rate on account masks, leading to a decrease in the level of account mask
failures. This enables the enterprise's remittance system to optimally
route remittances, thereby reducing the operating costs of the system and
to improve the customer experience by increasing the opportunity of a
customer to receive electronic bills to their convenience.

[0046] One embodiment of the invention can be described with reference to
FIG. 12, a flow diagram for payee creation and eBill activation. While
the flow chart depicts entities such as customer, payee mask, eBill mask,
and two types of payee the customer, it should be appreciated that this
system and method can be applied to any industry having any source for
the account number, any type of mask, and any type of target and still be
within the scope and spirit of the invention.

[0047] An account number is entered, shown here by a customer (1202). It
is determined whether the payee that the customer is requesting is a
remittance only payee or a combined remittance and eBill (1204). If the
type of payee is for remittances only, then it is determined if account
number cleansing instructions for the particular Merchant are available
(1206). If not, then the account number is trimmed (1208). If yes, then
the account number cleansing instructions are applied (1210). Then it is
determined if the account number cleansing instructions produce cleansed
account numbers (1212). If not, then the account number is trimmed
(1208). If yes, then it is determined if then cleansed account numbers
pass the payee mask (1214). If not, then the account number is trimmed
(1208). If yes, then a payee for that merchant is created using the
cleansed account numbers (1216). When and after the account number is
trimmed (1208), it is determined if the trimmed account number passes the
payee mask (1218). If not, the customer is asked to re-try, including the
customer re-entering the number or choosing other options (1220). If yes,
then a payee is created using the trimmed account number (1222).

[0048] If the type of payee is for the combination of remittances and
eBill activation or presentment, then it is determined if account number
cleansing instructions for the particular Merchant for remittances and
eBill payees are available (1224). If not, then the account number is
trimmed (1234). If yes, then the account number cleansing instructions
are applied (1226). Then it is determined if the account number cleansing
instructions produce cleansed account numbers (1228). If not, then the
account number is trimmed (1234). If yes, then it is determined if the
cleansed account numbers pass the payee mask and the eBill masks (1230).
If not, then the account numbers are trimmed (1234). If yes, then a payee
for that merchant is created using the cleansed account numbers and
eBills are activated (1232). When and after the account numbers are
trimmed (1234), it is determined if the trimmed account numbers pass the
payee mask and eBill masks (1236). If not, the customer is asked to
re-try, including the customer re-entering the number or choosing other
options (1240). If yes, then a payee is created using the trimmed account
number and eBills is activated using the trimmed account number (1238).

Account Number Cleansing Methodology

[0049] According to one embodiment of the invention, customer entered
account numbers are trimmed of leading and trailing spaces. A particular
account number cleansing instruction is comprised of any combination of
the following operations: [0050] changing the case of the characters to
either upper or lower case; [0051] using the syntax of a regular
expression, as follows: [0052] to define the set of valid characters;
all others are removed; or [0053] to describe the elements of an account
number that the system searches for and extracts, i.e. discarding all
other input, as well as how to reassemble and format the resulting
elements into an account number; [0054] adding characters, as follows:
[0055] specifying a character to pad with, including padding to the right
or padding to the left, and specifying the target length of the resulting
account number; or [0056] specifying a set of characters and whether to
use as a prefix or suffix.

Scrub & Match

[0057] Previously, when a customer adds a payee to a customer's customized
list of payees through a Bill Pay system, such as that of Wells Fargo, no
method for identifying whom the customer is attempting to pay existed. As
a result, whatever the customer entered was typically remitted via check.
The cost of a check is typically 4-8 times more expensive that an
electronic remittance. Electronic remittances are primarily created when
the customer picks a merchant off of a list in such a Bill Pay system and
successfully adds the payee to the customer's own list of payees. In one
embodiment of the invention, the Scrub and Match tool accepts as input
that which the customer entered and, using a flexible string variable,
associates it to one of the Merchants in the list of merchants, also
referred to herein as a Pick list. In addition, Scrub and Match can
customize the criteria based on a particular merchant and create a unique
criteria for each merchant in the pick list.

Auto Redirections

[0058] In one embodiment of the invention, Auto Redirections is an
application that allows users of the bill pay system to move payees from
one end point processor to another. When a customer submits information
to add a merchant through our system, a payee is created and is
automatically associated depending upon the configuration in the Online
Admin Tool to one of the member payment processors. Any payment that the
customer initiates after adding such payee is sent to that associated
payment processor. At times, it may be more beneficial to move this
payee, e.g. for reasons of costs or payment velocity, to another payment
processor. Automated Redirections allows users to achieve this objective.

Online Admin Tool

[0059] An embodiment of an Online Admin Tool, an application currently
used to manage all of the merchants in the Pick list is provided. At a
basic level, it allows an enterprise, such as Wells Fargo, to add
merchants and update addresses and account masks in a bill payment
system. Particularly unique is that it allows a user to set priority in
terms to which payment processor to first send a given payment. Each
payment processor has varying criteria for what it accepts. However,
being first the first payment processor in line is an advantage and helps
the enterprise to control its costs. The Online Admin Tool also allows an
enterprise to control processes such as Scrub and Match, Automated
Redirections, the Ebill Account Mask Handling Rules, and Payee Account
Mask Handling rules, all discussed in further detail herein. Preferably,
access to this tool is limited to a handful of people in a payee
management operations team. The tool is configured for multiple payment
processors instead of just one, thereby representing a significant cost
savings opportunity.

An Exemplary eBAM Implementation

[0060] This section describes an exemplary implementation of the account
handling rules and payee creation according to one embodiment of the
invention. This implementation is described by way of example and is not
meant to be limiting. One skilled in the art can readily apply the system
and method to other embodiments and to other industries that rely on
account numbers and be within the scope of the invention.

[0061] Table A hereinbelow presents a Glossary of terminology used herein.

TABLE-US-00001
TABLE A
Glossary
Account Mask: A text string which describes the attributes of the account
number
that the customer must enter to qualify for a particular eBill or payee.
Address Mask: The Pick list address the customer must select to qualify
for that
particular payment processor payee. Address masks are only used at the
Payee
level.
Biller (eBiller): When an electronic bill is available from a Merchant,
there is an
associated Biller tied to the Merchant. The Biller record provides the
Terms &
Conditions URL, validation tokens, hint text, restriction text, and
eBiller account
masks.
BPP: Bill Payment Processor. Accepts remittance (payments) on behalf of a
payee.
BSP: Biller Service Provider. An organization that enables billers to
present
electronic bills online.
Customer Payee: Identifies a Merchant or individual and the customer's
account
number with that Merchant or individual.
eBill: Electronic Bill. Also referred to as an online bill.
Formatted Account Number: The Trimmed account number that has been further
handled based on the defined account number handling rules for that
Merchant.
Mask: An expression that is used to qualify a customer's account number
for an
enterprise service, e.g. payment remittances and bill presentment.
Merchant: The Merchant is the actual merchant name displayed on the pick
list when
using Option 1 on the Add New Payee screen (Option 1--Search our list to
add your
new payee), or after selecting one of the results from Option 2--Locate
and add
your new payee by selecting the first letter in the name.
Processor Payee: The identification/information, e.g. processor payee ID
number,
address, account and/or address masks, provided by the payment processor
that
identifies a Merchant at that processor.
Processor Payee Record (Payee): The identification/information, e.g.
processor
payee ID number, address, account and/or address masks, provided by the
payment
processor for a Merchant. A Merchant can be associated to many payees,
including
payees from multiple payment processors, see Example 1 below. Payees can
also
be associated to multiple Merchants, see Example 2 below.
Example 1:
Merchant: Chase Visa/Mastercard
Payees: MVNT Payee 1--Chase Visa
MVNT Payee 2--Chase MasterCard
CheckFree Payee 1--Chase Visa
CheckFree Payee 2--Chase MasterCard
Example 2:
Merchant 1: Citibank Visa
Merchant 2: Citibank Mastercard
Payee: Citibank Visa/Mastercard associated to Merchant 1 & 2
Regular expression: A regular expression, sometimes abbreviated to
"regex," is a
way for a computer user or programmer to express how a computer program
should
look for a specified pattern in a string and then what the program is to
do when each
pattern match is found.
Restricted Merchant: A Merchant that is restricted by BPP. To activate an
eBill for
this Merchant, the customer's payee must be associated to the BPP
indicated in the
BSP table, the payee must be associated to the first order BPP in the BPP
hierarchy.
Top Level Merchant: The Top Level Merchant is found when using Option 2 on
the
Add New Payee Screen, i.e. Option 2--Locate and add your new payee by
selecting
the first letter in the name. In Wells Fargo Bill Pay, this is typically
the parent
company name, e.g. Wells Fargo.
Trimmed Account Number: The account number that the Customer entered with
any
leading and trailing spaced removed.
Unrestricted Merchant: A Merchant that is not restricted by BPP. To
activate an eBill
for this Merchant, there is no BPP specification or restriction in the BSP
table,
therefore the customer is eligible to activate eBill as long as the
customer's payee is
associated to one of the BPPs.

[0063] Bill Pay is experiencing a high rate of eBill account mask failures
when Customers attempt to activate eBills. Preliminary research indicates
that the issues are primarily the result of how Customers are entering
their account numbers when adding payees. Apparently, Customers are not
following the instructions that appear on Add Payee screens when adding
account information, specifically the account number, leading to the high
level of eBill activation rejections.

[0064] One embodiment of the invention develops a series of account number
handling rules that can be dynamically applied at the Merchant level
based on the Merchant supplied account masks. This series of account
number handling rules act as a scrubbing mechanism, cleansing the account
number a Customer enters to improve the match rate on eBill account masks
leading to a decrease in the level of eBill account mask failures.

[0065] In addition to the account number handling rules, the invention
also includes: [0066] a global trim rule to handle leading and trailing
spaces for all customer entered account numbers; [0067] a second pass of
the Account Mask routines if the system cleansed account numbers do not
pass both the Payee account mask and eBill account mask when adding
eBillers; [0068] a screen navigation change to allow for Customer re-try
of an account number that fails a Merchant eBill account mask; [0069] a
screen content change to assist users when re-entering account numbers
after an eBill account mask failure; and [0070] a report to assist the
Bill Pay administrators in the creation and maintenance of the account
cleansing rules.

Assumptions

[0071] Following is a list of assumptions for building and using the
exemplary eBAM system and method: [0072] Account number handling rules
are defined at the merchant level and applied globally to all of the
merchant's eBillers; [0073] A global trim rule, including trim leading
and trailing spaces, is applied to all personal payee activations; this
rule is for all payees, i.e. private and pick list; [0074] Pre-existing
accounts do not require updating when the account number handling rules
go into production because the new rules are applied as customers
activate eBills; [0075] Customer account number update functionality
within enterprise's existing bill payment system is not impacted;

[0086] In one embodiment of the invention, the Global Trim Rule is as
follows: [0087] Always trim leading and trailing spaces from the
account number entered by the Customer/agent/system; and [0088] Rule
applies to ALL Customer Payees.

Global Trim Rule Examples

[0089] Below are three examples of the Global Trim Rule detailing how the
rule extracts spaces from Customer entered account numbers. In these
examples an underscore ("_") denotes a space.

[0093] An exemplary implementation of the account handling rules and payee
creation according to one embodiment of the invention is provided
hereinbelow. This implementation is described by way of example and is
not meant to be limiting. One skilled in the art can readily apply the
system and method to other embodiments and to other industries that rely
on account numbers and be within the scope of the invention.

[0094] In one embodiment of the invention, the account number handling
process includes four steps as shown: [0095] extracting: The account
number is extracted from the Trimmed Account Number based on any defined
Merchant extract rules; [0096] formatting: The account number is
formatted in order to pass the Payee account mask and eBill account mask;
[0097] passing the account masks: The account number is passed through
the Payee account mask and eBill account mask routines; and [0098]
account number storage: Based on the results of the passing the account
masks, the system required account numbers are stored.

Extracting and Formatting of Account Numbers

[0099] For the purposes of this documentation the extracting and
formatting of account numbers is viewed as part of the same process, with
the newly defined account number handling rules encompassing both
extracting and formatting rules. The defined account number handling
rules according to one embodiment of the invention are as follows:
[0100] based on the range of Merchant eBill account mask and Payee
account mask specifications; [0101] defined at the Merchant level and
applied globally across the Merchant eBillers for that Merchant; [0102]
applied prior to the Payee account mask and eBill account mask routines
when a Customer is requesting the activation of an eBill; [0103] applied
to any Customer entered account number entry when requesting activation
of an eBill via the current pick-list functionality; [0104] applied to
any pre-filled account number or Customer updated account number entry
when a Customer is activating eBills for an existing Payee; [0105]
processed with the use of regular expressions as discussed in detailed
further hereinbelow; and [0106] dynamic in that a Bill Pay administrator
and the like have the ability to update the account number handling rules
on an as needed basis.

[0107] The following list shows generic examples of account number
handling rules according to one embodiment of the invention: [0108]
Extract numeric digits; [0109] Use only the first n digits; [0110]
Replace character "a" with character "b", e.g. replace hyphens with
spaces; [0111] Remove special characters; and [0112] Make alpha
characters upper case.

Account Number Handling Rules and Regular Expressions

[0113] In one embodiment of the invention regular expressions are employed
as part of the account number handling process. A regular expression is a
formula for matching strings that follow some pattern. In this use,
regular expressions are used to extract and format characters enabling
Customer entered account numbers, or system populated Customer account
numbers, to pass the merchant defined account masks.

TABLE-US-00006
TABLE F
Character Description
. Match Any Single Character
[ ] Match any character found within the brackets. Can also
be used to match a set of characters, or groups of sets.
i.e.: [0-9], [a-z, A-Z], or [0123].
[{circumflex over ( )}] Match any character not found within the brackets
Works just like above, only matches anything not listed.
i.e.: [{circumflex over ( )}0-9] matches everything but [0-9].
{circumflex over ( )} Designates the start of line.
$ Designates the end of line.
* Match 0 ore more occurrences of preceding regular
expression.

[0115] Three examples of Regular Expressions are as follows:

Example 1

[0116] [0-9]{3}\-[0-9]{2}\-[0-9]{4} Matches all numbers of the form
123-12-1234

Example 2

[0116][0117] [0-9]{3}\-?[0-9]{2}\-?[0-9]{4} Matches all numbers of the
form 123-12-1234 or 123121234

Example 3

[0117][0118] [0-9]{12} [A-Z]{2} Matches all numbers with the first 12
characters being numeric and the last two alpha, e.g. 123443218976DE

First Pass Functionality

[0119] When a customer is activating an eBill, at least one of each type
of account masks is passed successfully. Masks are presented for passing
as follows: [0120] Payee account mask: describes the attributes of the
customer account number to qualify for a particular Merchant Payee; and
[0121] eBill account mask: describes the attributes of the customer
account number to qualify for a particular Merchant eBiller.

[0122] For example, a merchant may require a set format divided by hyphens
and/or spaces or other type of account number requirements, with these
requirements being based in the merchant's account masks. The passing or
failing of these two account masks determines the following: [0123]
account number storage, described in detail hereinbelow; [0124] the
success or failure of eBill activation, described in detail hereinbelow;
and [0125] the Customer's screen navigation flow, described in detail
hereinbelow.

[0126] The first pass uses the cleansed account number.

Second Pass Functionality

[0127] In addition to the new account number handling rules a new Second
Pass of the Account Mask routines is implemented in one embodiment of the
invention. The second pass occurs when the system cleansed account
numbers do not pass both the Payee account mask and eBill account mask
when adding eBillers. New embodiment of functionality is as follows:
[0128] Customer enters account number when activating an eBill; [0129]
Customer's entered account number is cleansed based on the defined
account handling rules, with the formatted, i.e. cleansed, account number
run through the Payee account mask and eBill account mask; [0130] If the
first pass of the account masks has any failures, i.e. Payee account mask
and/or eBill account mask fails, then a second pass occurs; and [0131]
The second pass entails running the Trimmed Account Number, i.e. Customer
entered account number after the Global Trim Rule has been applied,
through the Payee account mask and eBill account mask.

[0132] The Second Pass of the Account Masks also: [0133] occurs if and
only if the Payee account mask and/or eBill account mask fail on the
first pass when adding an eBiller; [0134] includes the use of the Trimmed
Account Number only because formatted account numbers are run on the
first pass; and [0135] is applied prior to presenting the Account Number
Not Valid Screen, e.g. Screen 6.

[0136] In one embodiment of the invention, prior to the generation of
Screen 6, a Second Pass of the Payee Account Mask and the eBill Account
Mask with the trimmed Account Number is performed in an attempt to pass
the two account edit masks. Prior to the initial generation of Screen 6,
the trimmed account number is run against the first order BPP, with all
BPPs in the hierarchy being employed during any further generation of
Screen 6.

[0137] The screen flows of one embodiment of the invention are depicted in
FIGS. 1, 2a, 2b, and 3. One can refer to Table B for the map of screen
number reference to Figure number reference.

[0138] FIG. 1 shows first pass and second pass functionality according to
the invention 100. A first mask pass is performed 102 with a formatted
account number. Depending on the results, e.g. eBill=Pass and Payee=Pass,
the flow is determined. If eBill=Pass and Payee=Pass 108, then control
bypasses the second mask pass and Screen 6 and goes directly to a
different screen, depicted as Screen 5b-1 110, a payments options screen
for online bill payment. If any of the outcomes are fail 102a-c, then the
second mask pass with trimmed account number is performed 104 and 104a-c.
If eBill=Pass and Payee=Pass, then control goes directly to Screen 5b-1
110. If any of the outcomes contain a fail, then, control goes to Screen
6 106 and 106a-c. After performing the tasks on Screen 6 106a-c, control
continues as follows. If the merchant is either restricted or
unrestricted, control continues with FIG. 2a. The re-entered account
number 202 goes through the account number handling rules 204 process. If
the account number passed the payee mask 206, then it is checked against
the eBill mask 208. If it passes the eBill mask, then eBill is activated
210. If the account number does not pass the payee mask, then the
customer is shown Screen 6 212. If the customer does try again 222, for a
restricted merchant, control goes to FIG. 2B and for an unrestricted
merchant, control goes to FIG. 3. If the customer does not proceed, the
customer is shown Screen 7 214 and can either chose to add the payee as a
personal payee 216 or is shown Screen 0 218, where the customer can add a
new payee. If the account number did not pass the eBill mask 208, then
Screen 6 is shown to the customer 220. If the customer does try again
224, for a restricted merchant, control goes to FIG. 2B and for an
unrestricted merchant, control goes to FIG. 3. If the customer does not
proceed, the customer is shown Screen 7 226 and can either chose to add
the payee from a pick list 228 or is shown Screen 0 230, where the
customer can add a new payee.

[0139] With reference to FIG. 2B (Diagram B), essentially the same first
pass and second pass steps are performed. The exception is that control
is sent to the bill payment processor (BPP) when the account number
passes the payee mask 252 and 254. Again, if the merchant makes eBills
available, then the customer can add a payee from a pick list 256, 258,
and 260. Otherwise, the customer adds the payee as a personal payee and
the enterprise remittance system sends a check out to the payee 262.

[0140]FIG. 3 shows the same steps as FIG. 2B, except that when the
account number does not have to pass through the bill payment processor
302 but passes the eBill mask 304, then the eBill process for that
merchant is activated 306, which was not possible for a restricted
merchant.

[0141] FIG. 4 shows an Add New Payee screen that is prompting the user to
enter the account number with specific instructions 400. FIG. 5 shows an
Add New Payee screen that is prompting the user to enter the account
number with specific instructions 500 and that shows a business name as
it appears on the bill 502. FIG. 6 shows an edit payee screen 602 where
the customer can choose a payment option 604. FIG. 7 shows a non-eligible
to receive bills electronically screen 700. FIG. 8 shows a payee
information screen 802. It further shows detailed payee information 804,
customer account information 806, bill presentment options for the
customer 808, and payment options from the customer 810. FIG. 9 shows a
payee management screen 902 of the numerous payees for a particular
customer. FIG. 10 shows an add new payee screen 1002 for when the account
number entered previously did not match the typical account number format
for this payee. The customer is prompted to re-enter the account number
in the space provided 1004. Also, the screen offers an account number
reflecting what the customer previously added and allows the customer to
select that number instead 1006. FIG. 11 shows an add new payee screen
1102 where the customer is given the choice two options for selecting a
payee from a pick list 1104 and 1106, or for manually entering a payee
1108, which, in one embodiment of the invention, means that the payee is
sent a check.

Account Number Storage

[0142] In one embodiment of the invention, after the Payee account mask
and eBill account mask routines are run, three system account numbers are
stored as follows: [0143] Customer Viewable Account Number: the account
number displayed to the Customer via the user interface; [0144] Remit
Account Number: the account number employed in the Bill Pay payment
process; and [0145] eBiller Account Number: account number employed for
eBill activation and deactivation along with the handling of ebills.

[0146] The account number format stored for each of the three types is
determined by the pass/fail results of the Payee account mask and eBill
account mask routines.

[0147] The technical solution may include a design in which a separate
regular expression is stored for each of the three account numbers. In
this embodiment, the business requirement is to have a single identical
regular expression for each of the three account numbers, i.e. Customer
Viewable, Remit and eBiller.

[0148] In one embodiment of the invention, there are two formats in which
the three system account numbers can be stored: [0149] Trimmed: The
identical account number that the Customer entered with only the Global
Trim Rule being applied; and [0150] Formatted (Cleansed): The Trimmed
account number that has been further handled based on the defined account
number handling rules for that Merchant.

Regular Expressions and the Three Stored Account Numbers

[0151] Following are example implementations for storing regular
expressions for each of the account numbers according to one embodiment
of the invention. The technical solution for account number storage in
one embodiment of the invention includes a design in which a separate
regular expression is stored for each of the three account numbers,
however the current business requirement is to have a single identical
regular expression for each of the three account numbers, i.e. Customer
Viewable, Remit, and eBiller. Following is a more detailed look at
available functionality and the business requirement for this embodiment
of the invention.

Available Functionality

[0152] Available functionality based on the technical design allows for
each of the three stored account numbers to have individual, i.e.
different, extract regular expressions and format regular expressions as
shown in the following Table G.

[0153] The business requirement for this implementation of one embodiment
of the invention is to have identical extract regular expressions and
format regular expressions for each of the three stored account numbers,
i.e. Customer Viewable, Remit, and eBiller. Employing the same extract
and format regular expressions for each of the stored account numbers
means that the three account numbers are the same.

[0154] All three stored account numbers employ the same extract regular
expression, i.e. Extract Regular Expression #1, and the same format
regular expression, i.e. Format Regular Expression #1, which leads to the
end result of the same account number stored for the Customer Viewable,
Remit, and eBiller account numbers. See the example in Table H below.

[0163] The Scenario 1 Steps and Account Number Handling Example is as
follows in Table K:

TABLE-US-00011
TABLE K
Account Number Account Number
Step Screen Number Handling Action Example
Customer selects Payee, 1a N/A N/A
i.e. This is my Payee
link
Customer selects NO to 2 N/A N/A
eBills
Customer enters their 3c1 (Consumer) N/A 7028312345310_ _ --
account number 3c2 (Business)
Global Trim Rule for N/A leading and/or trailing 7028312345310
leading and trailing spaces are removed from
spaces is applied, i.e. the Customer Entered
Customer Entered Account Account Number
Number becomes Trimmed
Account Number
No further account N/A N/A N/A
number handling rules
are applied, because
the Customer selects
NO to eBills
Trimmed Account Number N/A N/A 7028312345310
is used in the Payee
Mask routine with the
account number passing
the mask routine
Trimmed account number N/A N/A 7028312345310
is stored for the
Customer Viewable
Account Number
Trimmed account number N/A N/A 7028312345310
is stored for the Remit
Account Number

[0164] The Scenario 1 Account Number Storage Requirements are as follows
in Table L:

[0171] The Scenario 3 Steps and Account Number Handling Example are as
follows in Table Q:

TABLE-US-00017
TABLE Q
Account Number
Step Screen Number Handling Action Account Number
Customer selects Payee, 1a N/A N/A
i.e. This is my Payee
link)
Customer selects YES to 2 N/A N/A
eBills
Customer enters their 3a-1 (Consumer) N/A 7028312345310
account number 3a-2 (Business)
Global Trim Rule for N/A Leading and/or trailing 7028312345310
leading and trailing spaces are removed from
spaces is applied. the Customer Entered
Account Number
Payee account mask N/A N/A N/A
either passes or fails
and the eBill account
mask fails
No further account N/A N/A N/A
number handling rules
are applied, because
the eBill account mask
failed.
A second pass of the
Payee account mask and
eBill account routines
with the Trimmed Account
Number now takes place.
See Section on the
Second Account Mask Pass
functionality herein for
further information.
For this scenario the
second pass of the
account mask routines
results in the same
outcome, i.e. the Payee
account mask either
passes or fails and the
eBill account mask fails.
No further account 6 N/A 7028312345310
number handling rules
are applied, because
the eBill account mask
failed.
On eBill Account Mask
failure the Customer is
directed to Screen 6
and provided the
opportunity to re-try
their account number.
The Trimmed account N/A N/A 7028312345310
number is stored as the
Customer Viewable
Account Number.
The Trimmed account N/A N/A 7028312345310
number is stored as the
Remit Account Number.
eBiller Account Number N/A N/A N/A
storage is N/A

[0172] The Scenario 3 Account Number Storage Requirements are as follows
in Table R:

[0173] The Scenario 4 Definition: Activate eBills on existing Payee, with
the Customer Account Number, either pre-filled or entered by the
Customer, passes both Payee account mask and eBill account mask.

[0179] The Scenario 5 Steps and Account Number Handling Example are as
follows in Table W:

TABLE-US-00023
TABLE W
Account Number
Step Screen Number Handling Action Account Number
From any Bill Pay screen N/A N/A N/A
click on Payee Management
in the Bill Pay Menu
On the Payee Management 18 N/A N/A
screen, Screen 18, click
on the Edit icon next to
the desired payee to get
to the Payee Information
screen, Screen 8.5
In the Bill Options 8.5 N/A N/A
section of the Payee
Information screen, click
on the button "Start
receiving this bill
online" to get to
screen 3a-1/3a-2
Customer enters their 3a-1 (Consumer) N/A 7028312345310
account number 3a-2 (Business)
Global Trim Rule for N/A Leading and/or trailing 7028312345310
leading and trailing spaces are removed from
spaces is applied the Customer Entered
Account Number
Payee account mask either N/A N/A 7028312345310
passes or fails and the
eBill account mask fails
No further account number N/A N/A N/A
handling rules are
applied, because the
eBill account mask failed.
A second pass of the
Payee account mask and
eBill account routines
with the Trimmed Account
Number now takes place.
See section on the New
Second Account Mask Pass
functionality for further
information.
For this scenario, the
second pass of the
account mask routines
results in the same
outcome a pass
No further account number 6 N/A N/A
handling rules are
applied, because the
eBill account mask failed.
On eBill Account Mask
failure, the Customer is
directed to Screen 6 and
provided the opportunity
to re-try their account
number.
The Trimmed account N/A N/A 7028312345310
number is stored as the
Customer Viewable Account
Number.
The Trimmed account N/A N/A 7028312345310
number is stored as the
Remit Account Number.
eBiller Account Number N/A N/A N/A
storage is N/A

[0180] The Scenario 5 Account Number Storage Requirements are as follows
in Table X:

[0181] A Merchant that provides eBills may receive account number handling
rules. For a Sample Merchant, the following is presented: [0182] Sample
Merchant Information; [0183] Account Number Handling Rules; and [0184]
Account Number Handling Examples.

[0188] Following are five (5) account number handling examples for Sample
Merchant.

[0189] Table AA below illustrates Example 1:

TABLE-US-00027
TABLE AA
Account Number Account Number
Handling Action Handling Example 1 Notes
Trimmed Account N/A 6789999953319999 Global Trim Rule has
Number been applied to the
Customer entered
account number
Upper Case N/A 6789999953319999 Upper Case Rule not
applied to this
Merchant.
Extract {circumflex over ( )}[{circumflex over (
)}0-9]*([0-9]{4})[{circumflex over ( )}0- 6789999953319999 Special
characters
9]*([0-9]{4})[{circumflex over ( )}0- and alphas are
9]*([0-9]{4})[{circumflex over ( )}0- removed
9]*([0-9]{4}).*$ Four sets of
4 numeric characters,
between 0 and 9, are
extracted
Format $1 $2 $3 $4 6018 5999 5331 9999 The account number
is formatted into a
XXXX XXXX XXXX XXXX
pattern, i.e. 4 sets
of 4 numbers with a
space between the
sets.
Number employed in
attempting the First
Pass of the account
masks.

[0190] Table BB below illustrated Example 2:

TABLE-US-00028
TABLE BB
Account Number Account Number
Handling Action Handling Example 2 Notes
Trimmed Account N/A BR6789-9634-5673-4562 Global Trim Rule has
Number been applied to the
Customer entered
account number
Upper Case N/A BR6789-9634-5673-4562 Upper Case Rule not
applied to this
Merchant.
Extract {circumflex over ( )}[{circumflex over (
)}0-9]*([0-9]{4})[{circumflex over ( )}0- 6789963456734562 Special
characters
9]*([0-9]{4})[{circumflex over ( )}0- and alphas are
9]*([0-9]{4})[{circumflex over ( )}0- removed
9]*([0-9]{4}).*$ Four sets of
4 numeric characters,
between 0 and 9, are
extracted
Format $1 $2 $3 $4 6789 9634 5673 4562 The account number
is formatted into a
XXXX XXXX XXXX XXXX
pattern, i.e. 4 sets
of 4 numbers with a
space between the
sets.
Number employed in
attempting the First
Pass of the account
masks.

[0191] Table CC illustrates Example 3:

TABLE-US-00029
TABLE CC
Account Number Account Number
Handling Action Handling Example 3 Notes
Trimmed Account N/A 6789-9438-2211-5451BR Global Trim Rule has
Number been applied to the
Customer entered
account number
Upper Case N/A 6789-9438-2211-5451BR Upper Case Rule not
applied to this
Merchant.
Extract {circumflex over ( )}[{circumflex over (
)}0-9]*([0-9]{4})[{circumflex over ( )}0- 6789943822115451 Special
characters
9]*([0-9]{4})[{circumflex over ( )}0- and alphas are
9]*([0-9]{4})[{circumflex over ( )}0- removed
9]*([0-9]{4}).*$ Four sets of
4 numeric characters,
between 0 and 9, are
extracted
Format $1 $2 $3 $4 6789 9438 2211 5451 The account number
is formatted into a
XXXX XXXX XXXX XXXX
pattern, i.e. 4 sets
of 4 numbers with a
space between the
sets.
Number employed in
attempting the First
Pass of the account
masks.

[0192] Table DD illustrates Example 4:

TABLE-US-00030
TABLE DD
Account Number Account Number
Handling Action Handling Example 4 Notes
Trimmed Account N/A 6789-9438-2211-5 Global Trim Rule has
Number been applied to the
Customer entered
account number
Upper Case N/A 6789-9438-2211-5 Upper Case Rule not
applied to this
Merchant.
Extract {circumflex over ( )}[{circumflex over (
)}0-9]*([0-9]{4})[{circumflex over ( )}0- 6789-9438-2211-5 In this
example the
9]*([0-9]{4})[{circumflex over ( )}0- number would fail
9]*([0-9]{4})[{circumflex over ( )}0- the Extract regular
9]*([0-9]{4}).*$ expression leaving
the Trimmed Account
Number as the number
to be run against
the Payee account
mask and eBill
account mask routines.
Format $1 $2 $3 $4 6789-9438-2211-5 Since the regular
expression failed
produce an accept-
able result the
Trimmed account
number, 6789-9438-
2211-5, will be the
account number
employed in attempt-
ing the First Pass
of the account masks.

[0193] Table EE illustrates Example 5:

TABLE-US-00031
TABLE EE
Account Number Account Number
Handling Action Handling Example 5 Notes
Trimmed Account N/A 4871-5438-2211-5451 Global Trim Rule has
Number been applied to the
Customer entered
account number
Upper Case N/A 4871-5438-2211-5451 Upper Case Rule not
applied to this
Merchant.
Extract {circumflex over ( )}[{circumflex over (
)}0-9]*([0-9]{4})[{circumflex over ( )}0- 4871543822115451 Leading
Special
9]*([0-9]{4})[{circumflex over ( )}0- characters and
9]*([0-9]{4})[{circumflex over ( )}0- alphas are removed.
9]*([0-9]{4}).*$
Four sets of 4
numeric characters,
between 0 and 9, are
extracted
Format $1 $2 $3 $4 4871 5438 2211 5451 The account number
is formatted into a
XXXX XXXX XXXX XXXX
pattern, i.e. 4 sets
of 4 numbers with a
space between the
sets.
Number employed in
attempting the First
Pass of the account
masks.
This example account
number will fail the
Payee account mask
since the account
number is to begin
with "67899".

Screen Navigation Change

[0194] In one embodiment of the invention, a screen navigation change is
implemented to an existing Add Payee flow when adding eBills and when the
account number fails the eBill account mask.

Screen Navigation Functionality

[0195] One embodiment of the invention provides a screen navigation when a
customer passes a payee account mask and fails the eBill account mask. A
re-try screen, i.e. an Account Number Not Valid screen--Screen #6, is
presented to the customer. The following Table FF below details the new
screen navigation flow based on payee account mask and eBill account mask
pass/fails according to the invention:

TABLE-US-00034
TABLE HH
Field Existing CB New Error
Field Name Characteristics Required? Error Message Revised Error Message
Message
Label = "Re-enter 22 A/N, If field is left blank,
account number" Δ No pre-fill display the following message
(AS): Input required for Re-
enter account number.
If an invalid character has
been entered, display the
following message (AS): An
invalid character has been
entered. Please manually re-
enter information for the
following field(s): Re-enter
account number

TABLE-US-00035
TABLE II
Selection . . . Navigates to . . .
Δ How Do I . . . New browser window opens and displays How
Do I . . . main page.
"Try again now" button Restricted Merchant
If account number field is blank, display
error message (AS): "Input required for
Re-enter account number."
If the customer's trimmed and formatted
account results in at least one failed set
of masks (either payee or eBill or both),
then use the trimmed account against the
payee and eBill account masks (second pass)
to get the end result:
If the account passes the payee account
masks for the first order BPP, and passes
the eBill account mask, display screen 4a.
If the account fails all BPP payee masks
and fails the eBill account mask, redisplay
screen 7.
If the account passes the payee account
masks for the first order BPP, and fails
the eBill account mask, display screen 7
(payee will be added as a pick list payee
if customer wishes to proceed adding payee
on screen 7).
If the account passes the payee account
masks for the second or lower order BPP,
and fails the eBill account mask, display
screen 7 (payee will be added as a pick
list payee if customer wishes to proceed
adding payee on screen 7).
If the account passes the payee account
masks for the second or lower order BPP,
and passes the eBill account mask, display
screen 7 (payee will be added as a pick
list payee if customer wishes to proceed
adding payee on screen 7).
The scenario where an account fails all
BPP payee account masks and passes the
eBill account mask should never occur.
Unrestricted Merchant
If account number field is blank, display
error message (AS): "Input required for
Re-enter account number."
If the customer's trimmed and formatted
account results in at least one failed set
of masks (either payee or eBill or both),
then use the trimmed account against the
payee and eBill account masks (second pass)
to get the end result:
If the customer's account passes the
payee account masks for any BPP, and the
account passes the eBill account mask,
display screen 4a.
If the account fails all BPP payee masks
and the eBill account mask, redisplay
screen 7.
If the account passes any of the BPP payee
account masks, and fails the eBill account
masks, display screen 7 (payee will be
added as a pick list payee if customer
wishes to proceed adding payee on screen 7).
If the account passes the payee account
masks for the second or lower order BPP,
and the account fails the eBill account
mask, display screen 7 (payee will be
added as a pick list payee if customer
wishes to proceed adding payee on screen 7).
If the account passes the payee account
masks for the second or lower order BPP,
and passes the eBill account mask, display
screen 4a.
The scenario where an account fails all
BPP payee account masks and passes the
eBill account mask should never occur.
"Proceed with this Restricted Merchant
account number" button Use the results of the last pass before
the display of screen 6 to determine
navigation:
If the account passes the payee account
masks for the first order BPP, and passes
the eBill account mask, display screen 4a.
If the account fails all BPP payee masks
and fails the eBill account mask, redisplay
screen 6.
If the account passes the payee account
masks for the first order BPP, and fails
the eBill account mask, display screen 7
(payee will be added as a pick list payee
if customer wishes to proceed adding payee
on screen 7).
The scenario where an account fails all
BPP payee account masks and passes the
eBill account mask should never occur.
Unrestricted Merchant
Use the results of the last pass before
the display of screen 6 to determine
navigation:
If the customer's account passes the
payee account masks for any BPP, and the
account passes the eBill account mask,
display screen 4a.
If the account fails all BPP payee masks
and the eBill account mask, redisplay
screen 6.
If the account passes any of the BPP payee
account masks, and fails the eBill account
masks, display screen 7 (payee will be
added as a pick list payee if customer
wishes to proceed adding payee on screen 7).
The scenario where an account fails all
BPP payee account masks and passes the
eBill account mask should never occur.

Reporting

[0200] In one embodiment of the invention, to manage the updating of the
account number handling rules, more specifically the regular expressions
that are employed to drive them, a report is developed and provided to
monitor required changes in merchant account number handling rules.

[0201] The report provides relevant merchant eBiller information to Bill
Pay administrator system(s) relating to specific eBill account mask
failures and the account number handling rules. The report allows the
Bill Pay administrator to analyze changes to eBiller account masks that
may require updates to the defined account number handling rules for the
Merchant in question.

An Example Report Name

[0202] An example of a report name is EBILL ACCOUNT MASK--REGULAR
EXPRESSION FAILURE REPORT.

Report Definition

[0203] In one embodiment of the invention, the report is defined as
follows, i.e. title and content definitions of each column of the report.
BSP stands for Biller Service Provider, as shown hereinbelow in Table JJ.

TABLE-US-00036
TABLE JJ
Column
# Column Title Column Definition
1 BSP ID The BSP ID for the bill service
provider
2 BSP Name The BSP Name for the bill service
provider
3 Merchant Name The name of the Merchant for the
eBiller in queston
4 Merchant ID The ID of the Merchant
5 Current Format Rule The current extracting and formatting
for eBiller regular expression for the Merchant.
6 BLRMSK eBiller account mask(s)
7 eBiller-test account The test account number as it is
number pre-formatting stored prior to any account number
handling rules being applied
8 eBiller-test account The test account number as it appears
number post-formatting after all account number handling
rules have been applied, i.e. the
account number that fails the test
9 what account mask(s) A list of the failed account masks,
failed? Payee and/or eBill
10 Date Date in which the report is run in
mm/dd/yyyy format.

Report Sample

[0204] Following in Table KK is a sample eBill Account Mask Report
according to one embodiment of the invention.

[0205] For Sample Merchant 1, the test account number failed the eBill
account mask due to the Merchant making a change from inserting hyphens
between the number sets rather than the account number handling rule
defined spaces.

[0206] For Sample Merchant 2, the test account number failed the eBill
account mask due to the Merchant making a change from inserting spaces
between the number sets rather than the account number handling rule
defined hyphens.

[0207] Accordingly, although the invention has been described in detail
with reference to particular preferred embodiments, persons possessing
ordinary skill in the art to which this invention pertains will
appreciate that various modifications and enhancements may be made
without departing from the spirit and scope of the claims that follow.