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

Abstract:

Cash demand for a cash dispensing device is forecasted for individual
days, weeks and multi-day load periods. In one embodiment, an expected
value of withdrawal for any particular period, as well as an upper limit
on expected withdrawals for a given confidence level, are computed. The
technique facilitates the creation of a daily and multi-day withdrawal
forecast for a given ATM. The forecasts are also used to compute an
optimum load amount for a given load period (the period between loading
operations) for a given ATM, subject to given parameters (such as courier
cost, interest rate, transit time, desired confidence level, cost of
run-out, and the like) and given constraints (bundle size, maximum
capacity, possible delivery days, and the like). The forecasts are also
used to determine an optimal load period length and schedule.

Claims:

1. A computer-implemented method of forecasting withdrawals from a
dispensing machine, comprising classifying historical withdrawal data
into one or more data series, wherein at least one data series represents
a given time period; defining a model for use in modeling future
anticipated withdrawals from the dispensing machine in the given time
period, the model comprising a predictable component and a random
variation component; using the data series to compute a set of one or
more parameters of the model; and using the model to forecast withdrawal
demand for a given date in the future occurring on or in the given time
period.

Description:

[0001] This application is a continuation of Ser. No. 13/111,989, filed
May 20, 2011, now U.S. Pat. No. 8,231,049, which application was a
division of Ser. No. 11/157,238, filed Jun. 21, 2005, now U.S. Pat. No.
7,946,474, which application was based on and claimed priority to
application Ser. No. 60/581,533, filed Jun. 21, 2004.

BACKGROUND OF THE INVENTION

[0002] In the financial industry, automated teller machines (ATMs) are an
important means of providing quality customer service. ATMs provide
customers a convenient way to transact bank business while saving time.
Accordingly, financial institutions have significant incentive to ensure
that their ATMs are continuously available and functioning correctly.

[0003] ATM management services are well-known in the art and include,
among others, cash replenishment, computerized monitoring system, full
first-line maintenance (including replacement of all consumables, screen
software uploads and emergency call-outs) and computer video link
monitoring. ATM software products are also widely available and include
cash management predicting functions. One such product is ATM Manager
Pro, available from e-Classic Systems, Inc. This product enables a
financial institution to forecast cash out dates and to propose
appropriate replenishment amounts, to generate cash orders and loads, to
balance vault cash and other cash accounts, and to reconcile settlement
details by terminal or by date. In ATM Manager Pro, a model of a
withdrawal pattern is generated for a particular machine and then
averaged over a given time period (e.g., 28 days) to create a "per day"
average for the period. In addition to these known products and services,
the patent literature also describes techniques for ATM management such
as computer-implemented cash flow predictive algorithms. One such
technique is described in U.S. Pat. No. 5,799,288 to Tanaka et al. This
patent describes a money management system to predict and manage a
demanded cash amount for an ATM. In particular, the system cumulatively
stores transaction data from an ATM and uses that data to develop a model
of the withdrawal pattern. That model uses data for one (1) year from a
number of sources and calculates weights for a number of qualitative
factors. A prediction algorithm calculates and predicts demanded cash
amounts within a designated time for the machine based on the model.

[0004] These and other known approaches provide useful information to the
financial institution or other ATM service provider, but their cash
demand forecasts are relatively simple and do not take into consideration
true machine use situations or the particular ATM's operating
environment. Thus, for example, a financial institution might expect a
withdrawal pattern on Fridays to be somewhat similar over a given month
but perhaps very different from the withdrawal pattern on Wednesdays, as
Fridays are often pay days or days in which users withdraw money for
weekends. Depending upon the location of the ATM, withdrawals also may be
affected by season, e.g., ATMs located in ski areas experience higher
demand in winter and lower demand in the summer; conversely, ATMs located
in towns near beaches experience higher demand in summer and lower demand
in winter. An institution may also experience unexpected demand from a
given machine in close proximity to a venue at which a given concert or
special event is taking place. Prior art cash demand forecasting
techniques are often based upon rules of thumb, relying upon experienced
operators, and they are not robust enough to provide meaningful forecasts
for these and other "real-world" situations. As a result, ATMs are often
loaded with extra funds, reducing the profits of the ATM operator, or
they are loaded with not enough funds, resulting into unsatisfied
customers and lost revenue for the ATM operator.

[0005] The present invention addresses the long felt need in the art for
improved techniques for forecasting cash demand and load schedules for
automated teller machines.

BRIEF SUMMARY OF THE INVENTION

[0006] It is an object to provide a method of and apparatus for
forecasting cash demand for an automated teller machine (ATM) or any
other cash dispensing devices for individual days, weeks and multi-day
load periods. In one embodiment, an expected value of withdrawal for any
particular period, as well as an upper limit on expected withdrawals for
a given confidence level, are computed. The invention facilitates the
creation of a daily and multi-day withdrawal forecast for a given ATM.

[0007] It is a further object to describe techniques for using such
forecasts to compute an optimum load amount for a given load period for a
given ATM, subject to given parameters (such as courier cost, interest
rate, transit time, desired confidence level, and the like) and given
constraints (bundle size, maximum capacity, possible delivery days, and
the like).

[0008] It is still another more general object to determine an optimum
period between loads in an ATM given desired confidence levels and
certain criteria, e.g., that money put into the ATM is going to be
sufficient for anticipated demand, the cost of the ATM running out of
money as lost revenue, and a cost of doing emergency loads.

[0009] Another more particular object is to provide an ATM cash demand and
load scheduling system that monitors cash in an ATM during a load period
(the period between loading operations) and that facilitates potential
corrective action because actual withdrawals exceed forecasted
withdrawals or, in the alternative, because the ATM contains excessive
funds on its upcoming regularly scheduled load date, e.g., due to much
lower withdrawals than expected, or due to the ATM becoming unavailable
(for dispensing money) for a given portion of the load period.

[0010] The subject matter herein also enables an ATM system operator to
answer necessary "what-if" questions and to optimize its operations
taking into account variables affecting operation. Examples of such
variables include, without limitation, the constraints on when machines
can be loaded, machine capacity for holding cash in different
denominations, acceptable likelihood of cash being run out, interest
rates, money transit times, cost of loading cash, and the like. In a
representative embodiment, the invention is a self-learning system that
automatically configures itself from the withdrawal data for each ATM
separately.

[0011] In an illustrative embodiment, a computer implemented ATM cash
forecasting and load scheduling system preferably has a number of
components: data clean up to address exception conditions, model
building, forecasting, optimization, and monitoring. Each of these high
level components may be implemented in software executable in given
commodity hardware having an operating system.

[0012] Preferably, the forecasting and load scheduling system operates on
a "per ATM" (or, more generally, per machine) basis. It can also operate
on a per site basis, where a site is defined as being a collection of
ATMs that are at the same location and placed such that, if one ATM is
out of funds, the customer can use another machine very conveniently so
that no revenue is lost to the service provider. In an illustrative
embodiment, a model building component preferably operates by separating
incoming cash withdrawal data (e.g., a data stream provided by a data
collector) by day of the week, e.g., Tuesday, Saturday, and the like. The
data for a given day optionally is then "corrected" (i.e. adjusted or
modified) to address one or more "special" situations or anomalies, such
as machine breakdown, the existence of a given event that might cause
short-term ATM "flash" crowds, and the like. After this "day of the week"
data is adjusted for "special" situations or anomalies, the modeling
component preferably builds cash demand (withdrawal) models that are used
to generate load data (load period, load schedule, load amount) for the
given ATM. The modeling component preferably operates as follows. For
each day of the week (e.g., a Thursday), the component builds a model of
withdrawals for that day of the week, using a data series consisting of
historical cash withdrawals on that day of the week. This model
preferably is built by fitting a mathematical function containing
non-periodic (linear and non-linear) components as well as periodic
components, to the historical withdrawal data. This function fitting can
be done using standard non-linear regression analysis in a single step,
or in multiple steps. After computing the parameters of the modeling
function, preferably the modeling component determines the amount of
random variation in the historical withdrawal that is not explained by
the mathematical function fitted to the data. Thus, for a given day of
the week, the modeling component computes parameters of a modeling
function, and an unexplained random variation.

[0013] For each calendar date, and given a desired confidence level and
the forecasting model for the day of the week for that date, the
invention generates a forecast of expected cash withdrawals. The forecast
preferably includes:

[0014] expected value of the money to be
withdrawn, and

[0015] an "upper limit value" such that the likelihood
that the withdrawals will be less than or equal to the upper limit is
given the "confidence level." The forecast of expected withdrawals
typically is based on the modeling function for the day of the week and
the unexplained random variation for the day of the week. This forecast
for the date preferably is then corrected for expected special situations
not already taken into account by the modeling function.

[0016] In like manner, a forecast for a multi-day period may be created,
preferably by aggregating forecasts for each of the dates in the period;
in such case, forecasts for each date are computed, as before, using the
models for the corresponding days of the week. For a given ATM, given
load period and confidence level, the upper limit on the amount of money
expected to be withdrawn during this multi-day load period then is the
amount of money that is recommended to be loaded in the ATM. (A load
period is defined by the date on which the ATM will be loaded with
additional money and the length of the load period, i.e., the number of
days until the date of next load.)

[0017] A load schedule optimizing component computes optimum load schedule
and, in particular, optimum load period length. In particular, for each
potential size multi-day load period beginning with a projected load
date, preferably the module computes a total cost of money based on the
forecasted daily withdrawals (and upper limits on total withdrawals),
preferably taking into consideration given cost parameters (e.g., courier
cost, interest rate, money transit time, bundle size, and the like).
Then, the component computes an optimum number of days between loads,
minimizing a unit cost of loading money into the ATM by taking into
account money delivery or scheduling constraints, and a maximum capacity
of the ATM.

[0018] The monitoring component preferably operates during a current load
period as new data becomes available on actual withdrawals. The component
compares the actual withdrawals against the forecasted withdrawals. Using
the old forecast of withdrawals for the future days, differences between
actual withdrawals and the forecasts for the days already past in the
current load period, as well as the actual funds that remain available in
the machine, the component computes a projected ATM "run out" date and a
forecast of residual amounts on the expected next load date. The
component then performs (or recommends performance of) necessary or
desirable funding corrections for the machine.

[0019] The foregoing has outlined some of the more pertinent features of
the invention. These features should be construed to be merely
illustrative. Many other beneficial results can be attained by applying
the disclosed invention in a different manner or by modifying the
invention as will be described.

BRIEF DESCRIPTION OF THE DRAWINGS

[0020] FIG. 1 is a simplified block diagram illustrating a distributed
environment in which the present invention may be implemented;

[0021] FIG. 2 illustrates a process of separating incoming data into an
independent data series, one for each day of the week, according to a
first feature of the present invention;

[0022] FIG. 3 illustrates how a data element in a data series may be
processed according to one embodiment of the present invention;

[0023] FIG. 4 illustrates a process of computing statistics based on the
data series according to an illustrative embodiment of the invention;

[0024] FIG. 5 illustrates a process of building a model for a data series
according to the present invention;

[0025] FIG. 6 illustrates a process of forecasting cash demand for a given
day according to the present invention;

[0026] FIG. 7 illustrates a process of updating a forecast to consider
special events;

[0027] FIG. 8 illustrates a process of generating a forecast for a
composite period according to the present invention;

[0028] FIG. 9 illustrates a process of computing cost for a load period
according to the present invention; and

[0029] FIG. 10 illustrates a process of determining optimum load period
length that minimizes per unit cost according to the present invention.

DETAILED DESCRIPTION OF AN ILLUSTRATIVE EMBODIMENT

Glossary

[0030] The following are definitions for various terms that are used in
the descriptive text that follows:

[0031] date: generally refers to calendar date; however, when "date" is
used as an argument or input to a mathematical function, the calendar
date preferably is translated into a number of days since a reference
date, e.g., assuming Jan. 1, 2000 as a reference date, Jan. 1, 2004 is
translated into 1461 (days since Jan. 1, 2000);

[0032] load date: date on which an ATM (or other dispenser) is loaded with
new funds or items being dispensed, as the case may be;

[0033] load period: a time period between one load (date) and the next
load (date); a time between a first load of a given machine and a next
load of the given machine is sometimes referred to herein as a "load
period";

[0034] load period length: a number of days between two consecutive load
dates;

[0035] load amount: an mount of money that should be put in a given ATM;

[0036] residual: an amount of money left in a given ATM at the end of a
load period; often, upon a next load the residual is removed and replaced
with new funds; add/swap: a load time option; when loading a given ATM,
removal of all remaining (residual) money before reloading is a swap;
otherwise, it is an add;

[0037] capacity: a maximum amount of money that a given ATM or a money
dispenser may hold; the value is usually specified in terms of an amount
of money (e.g., $) that, in turn, is derived from a bill thickness, stack
height and a bill denomination; for machines that can dispense cash in
multiple denominations, the capacity may be different for each
denomination;

[0038] daily withdrawal: an amount of money (or other denomination, such
as stamps) withdrawn on a particular date, also referred to as a data
element (see below).

[0039] data element: a tuple (time, value, value type), e.g., an amount of
total money withdrawn on the date, amount of money withdrawn in given $
bill denominations on the date, the number of stamps withdrawn on date,
or the like;

[0040] overall data series or data series: a series of data elements for
all observations during an entire historical period, irrespective of the
day of the week;

[0041] data series by day of the week: a series of data elements for
selected observations for a same day of the week (e.g., Monday) during a
historical period;

[0042] model: a set of functions and other quantities that describe a
withdrawal pattern associated with a given ATM; a model may have several
components including a predictable component (as defined by a modeling
function) and an unexplained or random variation component.

[0043] modeling function: a mathematical function or method representing a
predictable component of withdrawals (for a specific day of the week, a
specific ATM, or the like); the function may have several components,
such as periodic components and non-periodic components;

[0044] unexplained or random variation: standard deviation of the
difference between actual withdrawal and value computed by the modeling
function for dates in the historical data series for that model;
typically computed as a result of the regression;

[0045] model for a date: a model corresponding to the particular day that
corresponds to the day of the week for that date;

[0046] periodic: shall mean having repeated cycles;

[0047] non-periodic: shall mean not having repeated cycles;

[0048] linear change: refers to when different points fall on a straight
line;

[0049] non-linear change: refers to when different points do not fall on a
straight line; the change may be periodic or non-periodic;

[0050] simple periodic function: a continuous function of given amplitude
(a), period (p) (1/frequency) and phase shift (ph), e.g., a sine function
such as a*sin(2*π*date/pd-ph); note that a cosine function also is a
simple periodic function, as it is essentially a sine function shifted by
90 degrees or π/2 radians; further, in actual implementation, the date
variable in the above sine function is taken as number of days since some
reference date;

[0051] compound periodic function: a periodic function that is a
combination of simple periodic functions; the component functions can
have different periods or phases, e.g.,

[0052] A four component
periodic function, where each component is a simple periodic function
with independent period and phase:

[0053] forecast for a date (some times also referred to as daily
forecast): a forecast of the amount of money expected to be withdrawn
from an ATM on the date; this forecast typically has two components:

[0054] expected value of the money to be withdrawn on the date, and

[0055] an "upper limit value" such that the likelihood of withdrawals on
that date are less than or equal to the upper limit is given "confidence
level".

[0056] forecast for a period: a forecast of the amount of money expected
to be withdrawn from an ATM on the period. It has two components:

[0057] Expected value of the money to be withdrawn during the period, and

[0058] An "upper limit value" such that the likelihood of withdrawals
during that period are less than or equal to the upper limit is given a
"confidence level"

[0059] (desired) confidence level in a forecast: a (desired) likelihood of
withdrawals during that period are less than or equal to the upper limit
component of the forecast (specified amount);

[0060] forecasted residual: a forecast of the amount of money expected to
be remaining in the ATM at the end of current load period; the forecasted
residual also has two components

[0061] expected value

[0062] lower limit on forecasted residual.

Context Overview

[0063] FIG. 1 illustrates an overall context in which the invention may be
implemented. End users withdraw money from ATMs 100 at random points. An
ATM maintains information about the withdrawals. ATM management software
102, such as ATM Manager Pro® from eClassic Systems, Inc.,
periodically collects this data at a data collector 104. This software
periodically sends consolidated withdrawal information to a forecasting
system 106, which implements the model building, forecasting,
optimization and monitoring functions that were described generally
above. Such data may be provided as a stream, in batch form, or in any
other convenient manner. Generally, the forecasting system 106 records
the withdrawal information, processes it, builds withdrawal models,
determines when an ATM may run out of money, and determines the amount of
next load and when the next load should be made, preferably taking into
account a number of parameters including pre-existing load schedule and
withdrawal patterns as will be described below. The forecasting system
106 also prepares and presents a number of reports 108 and graphs 110 for
viewing by analysts and operators. The forecasting system 106 also allows
the analysts to ask a number of "what if" questions to optimize the
operations. Information exchange between different modules can be done in
a number of different ways, e.g., a data collector can send the
information to the forecasting system or the latter can ask for the
information from a data collector. The devices can be operated over any
convenient network, e.g., the Internet, a local area network, a dedicated
private network, or the like. Communications between devices may rely
upon well-known transport protocols.

Creating Withdrawal Data Series for Each Day of Week

[0064] In the case of ATMs, typically the incoming data is an amount
(total cash withdrawals) on a given date. As data is collected over a
given time period, the incoming data may be considered to be a "series"
(i.e., a number of objects arranged or coming one after the other in
succession). Over a given time period, incoming data may be treated as
one data series, where withdrawal on each date represents a sample of a
random variable. This random variable has a probability distribution
function (PDF), and this PDF is a function of a number of parameters.
Typically, however, there are significant intrinsic differences in the
withdrawal patterns for a given ATM on different days of the week. For
example, the withdrawal pattern on Fridays during a given month or season
may be somewhat similar but very different from the withdrawal pattern on
Wednesdays because Fridays are often pay days or days in which users
withdraw money for weekends. The forecasting system 106 of the present
invention addresses this and other real-world considerations, as will be
seen.

[0065] According to the invention, in an illustrative embodiment, as
mentioned earlier, historical withdrawal data is divided into separate
datasets or data series by day of the week, i.e., separate datasets for
Monday, Tuesday, and so on and so forth; the entire dataset may be
considered an aggregation of these separate datasets. As a
generalization, according to the invention, preferably the incoming data
series is processed and treated as an aggregate of a number of
independent data series. FIG. 2 shows the process of separating incoming
data (presumably received into the system on a daily basis over some time
period) into independent data series according to this technique. In this
example, historical data 200 for the given ATM and any periodic update
data 202 is supplied to a data series separator function 204, which
generates independent data series DS1 . . . DSn. The data series
separator function 204 is implemented as a program, process, an execution
thread, or the like and simply parses the incoming data into the separate
buckets. Thus, in the illustrative embodiment, DS1 represents the data
series for Mondays, DS2 represents the data series for Tuesdays, and so
forth.

Cleaning Observed Data/Improving Quality of Raw Data for Modeling

[0066] An institution might expect the withdrawals on a specific date, a
data element, to fit a given pattern or model for the day of the week
corresponding to the date (i.e., the withdrawal for the date is a sample
of the corresponding random variable for the day). This is not always the
case, however, as there can be any number of situations that cause this
assumption to be untrue. Examples of such situations include, without
limitation, the ATM breaking down (and thus having relatively low
withdrawals), the ATM facility being closed due to a holiday, a special
event in the neighborhood, e.g., a concert or a game near the location
where the ATM is located, and so forth. Thus, according to the invention,
it is desirable to analyze the incoming data elements against a number of
criteria to determine whether the observed data is an outlier as a result
of conditions like the ones mentioned above. These criteria include,
without limitation, historical statistics of withdrawal for the day of
the week, any previous forecast of the withdrawal done at the load time,
any special event specification for that date for the ATM, and any
thresholds for determining special and exception situations. Some
examples, without limitations, of the tests that can be performed to make
such a determination are:

[0067] If (observed value>(historical mean
withdrawal for the day of the week+3*standard deviation of the withdrawal
for the week)) then {withdrawals for that date were probably
exceptionally high},

[0068] If (observed value<(historical mean
withdrawal for the day of the week) and (the balance at the end of the
day was=0)) then {the ATM ran out that day},

[0069] If (observed
value<(historical mean withdrawal for the day of the week-2*standard
deviation of the withdrawal for the week)) and (the balance at the end of
the day was>0)) then {either the withdrawals for that day were
exceptionally low for that date or the machine broke down}. Note that
these tests are merely representative, and there is no requirement the
withdrawal data be "corrected" with respect to all of these criteria, or
any of them.

[0070] In an illustrative embodiment, it is desirable to determine if an
exception has occurred on the date (e.g., ATM ran out or broke down) or
if the date is a potential candidate for being an unanticipated or
unspecified special event. If there is no potential exception or special
situation, then preferably the data element (the data received for the
date in question) is placed in the processed data series. When a
potential exception situation or special event is identified, corrective
action is taken on the observed value to improve the quality of the data
series, and optionally appropriate messages are provided to enable the
operator. Corrective actions include, for example, substituting the
measured value (for the date in question) by an historical average or
data from a previous forecast, eliminating from the data series the data
for this date (the observed value being evaluated), or the like. Upon
receiving the notification messages, operators can review and optionally
define additional past or present special events, which may then be added
to those already in the database.

[0071] Such data handling is illustrated in FIG. 3 and utilizes a data
element processing function (a "data element processor") 300. As
described above, this function is implemented in software executable on
the computer. The data element processor preferably receives, as one or
more inputs: historical statistics 302 (including mean, standard
deviation, maximum and minimum), any exception and special event data 304
that has previously triggered a threshold, a special event specification
303 that defines a set of one or more special events that have been
specified by the operator, and a forecast 305 for the date corresponding
to the observed data element For an input data element (labeled new,
actual data element) 306, the data element processor 300 tests to
determine whether an exception condition has been met at 308 or whether
the data element represents a special event candidate at 310. If so, the
data element is not put in the processed data series, and instead,
operator is or may be notified to perform an appropriate analysis at 312.
Thus, for example, the operator may determine to include the new data
element in a special event database 314 going forward. The special event
database 314 generates the special event specification 303. Each element
316 processed by the data element processor 300 is stored with its
appropriate data series at 318. The data series 318 is sometimes referred
to below as a processed data series DSi.

Initial Data Load and Ongoing Processing

[0072] The steps of separating/classifying data into data series (FIG. 2)
and processing by filtering out exception/special situations (FIG. 3)
preferably are performed as new data becomes available to the system
through the one or more data collectors (or other means). When data
becomes available for an ATM for the first time, it is desirable to load
into the system all available data for the ATM and to compute historical
statistics. This is illustrated in FIG. 4 for a given data series 400. In
this example, a set of statistics (mean, maximum, minimum, standard
deviation) 402 is computed by a computation process 404. As needed, data
can be processed against the historical statistics for the purposes of
exception and special event processing.

Withdrawal Models

[0073] With the above as background, the following describes how the
forecasting system of the present invention builds a model for the
withdrawal data series that is then used for prediction, namely,
predicting withdrawal amounts by date, forecasting demand during a
period, computing load amounts for a given ATM for given period and
confidence level, forecasting residual amounts in current load period for
an ATM and optimum load periods and schedules.

[0074] Generally, no mathematical function of a given set of factors can
fit an observed data series perfectly, i.e., given a modeling function
the data series, the difference (actual value- the value computed by the
model function) for each of the dates in the data series is not
necessarily zero. Thus when a modeling function is defined to represent a
data series, one can compute the remaining error corresponding to the
each element (date). This leads to an important insight of the present
invention, namely, that the variation in the withdrawals may be modeled
by two components:

[0075] A predictable component that is a function,
f(date), and

[0076] A random variation component that is not explained by
factors represented in the model

Modeling Function

[0077] For given withdrawal data series, such as a processed withdrawals
data series for Mondays, one can define a modeling function
fmonday(date) to model the predictable components of withdrawals.
When it is not necessary to distinguish the underlying weekday (the
primary identifier of independent data series), the following description
will refer to this function simply as f(date).

[0078] According to an illustrative embodiment of the invention, this
modeling function, f(date), preferably has several different components:

[0079] a non-periodic component,

[0080] a periodic component which
itself preferably has one or more components:

[0081] continuous or
piecewise continuous periodic component, and

[0082] a quasi-periodic,
discrete valued component,

[0083] a special situation component, and

[0084] an environmental and other auxiliary factors component.

[0085] In one particular embodiment, but without limitation, the modeling
function is specified as follows:

[0086] The following explains the above-identified modeling function in
more detail, first by classifying the various parts of the function into
the component categories mentioned earlier. Computation of the parameters
of the model is also described.

[0089] b)
Note that this component can be expressed more generally as
wnp0+wnp1*(date) or
wnp0+wnp1*(date)+wnp1*log(date) and many other such
variations, although the fixed component wnp0 can be omitted.
Continuous or piecewise continuous periodic component:

[0091] b) Other periodic functions, such as Fourier Series,
can be used instead of these functions; one such example is a Fourier
Series with period P and N-Harmonics is defined as
FSN(x,p)=Σi=1, . . . ,
N(ai*cos(2*π*x/p)+bi*sin(2*π*x/p));

[0092] c) The number
of periodic components can be increased; further, rather than fixing the
periods, the periods can be determined automatically through regression
analysis;

[0093] d) it is generally not necessary to represent variation
within a month using periodic components as, preferably, those are taken
into account by the quasi-periodic components below. Quasi-periodic,
discrete valued component:

[0104] c) Note that
each of the above functions provides a Boolean value (0/1); for
computational purposes, it is helpful to create a set of corresponding
Boolean variables, e.g., isday1, . . . , isday31, for each
date;

[0105] d) If withdrawal data has already been separated into
separate data series by day of the week, isweekday(date, i) functions are
not needed, as the values of these will be the same for all data elements
in the series. Special situation component:

[0107] i) ispayday(date)=1 if "date is
a payday in ATMs locality" else 0; this information can be obtained
either from ATM profile or by heuristics, such as pay cycles are
bi-monthly (15th and 30th or 31st or the working day
before these if these dates fall on weekends or are holidays);

[0108] ii)
isholiday(date)=1 if "date is a holiday in its locality" else 0; this
information can be obtained either from ATM profile or by heuristics,
such as look up in a global calendar;

[0109] iii) ispreholiday(date)=1 if
"date occurs before a holiday in its locality and has significant
activity as a result" else 0; an example will be day before Thanksgiving
in USA; this information can be obtained either from ATM profile or by
heuristics, such as look up in a global calendar.

[0110] iv)
ispostholiday(date)=1 if "date occurs after a holiday in its locality and
has significant activity as a result" else 0; an example will be a few
days after Thanksgiving in USA; this information can be obtained either
from ATM profile or by heuristics, such as look up in a global calendar;

[0111] b) As an example, for date Mar. 15, 2001, using the above
mentioned heuristic for payday:

[0112] i) ispayday(Mar. 15, 2001)=1

[0113] ii) isholiday(Mar. 15, 2001)=0

[0114] iii) ispreholiday(Mar. 15,
2001)=0

[0115] iv) ispostday(Mar. 15, 2001)=0

[0116] c) These are
common factors, but this list is not exhaustive.

[0117] d) These factors
can be represented as Boolean variables. Environmental and other
auxiliary factors component:

[0118] Σi=1, . . . , 3 wsnowi*issnowinrange(date,i)

[0119] +Σi=0,1, . . . , 12 wtempi*istempinrange(date, i)

[0120] e) Where:

[0121] i) issnowinrange(date,i)=1 if "snow on the date
was in range i" else 0, where the ranges are defined as 1=Light
(0''-3''), 2=Moderate (4''-7'') and 3=Heavy (8''+)

[0122] ii)
istempinrange(date,i)=1 if "temperature on the date was in range i to"
else 0, where range(1)=Temp<10, range(2)=11-20, . . . ,
range(11)=101-110 and range(12)=111+; note that one can easily define
ranges in a different way.

[0123] f) As an example, on Mar. 15, 2001,
when there was no snow and day time high temperature was 42 degrees,

[0126] g) Note that these factors, snow
and temperature, are merely representative and is not exhaustive or
limiting. Preferably, each of the variables, e.g., snow and temperature
on the date in the example above, should be such that a forecast of their
value can be determined in advance for forecasting purposes; before these
factors can be incorporated in the model, historical values of these
factors will also need to be gathered either along with the withdrawal
data or independently.

[0127] h) These factors can also be represented as
Boolean variables.

Computing Model Parameters

[0128] As can be seen, the modeling function, f(date), is a combination of
several sub-functions and variables, weights for each of which (called
model parameters) are represented by w--i, e.g., wnp1, wc12,
wdi. The value on the date of given variables (e.g., amount of snow
on date) and the amount of withdrawal, are measured and the value on the
date of individual sub-functions (e.g., cos) or derived-variables (e.g.,
issnowinrangei or isdayi--see discussion below) are derived
from date or ATM profile (see below). Preferably, the model parameters
are determined by performing non-linear regression on the resulting
equations using standard regression techniques and tools. The purpose of
the non-linear regression analysis is to compute the values of these
parameters such that the standard deviation of the error, or standard
error of estimate, is minimized. Thus, for example, the regression step
provides:

[0129] i) model parameters: w--i, e.g., wnp1, wc12,
wdi.

[0130] ii) standard error of estimate (or model) or StdErr

[0131] In an illustrative embodiment, one could use non-linear regression
techniques implemented in a software package, such as the commercially
available package NLREG. Other software packages, such as Datafit, employ
a similar approach and may be used. The values of these parameters also
can be determined using a multi-step analysis method employing functions
built into commercial spreadsheet programs such as Microsoft Excel.
Several other optimization or search techniques can be employed to
determine the values of these parameters. Additional details for carrying
out these tasks are provided below.

Regression Details

[0132] Several commercially available tools such as NLREG and Datafit are
designed specifically for doing regression. These provide both a
programming interface that allows these tools to be embedded or called
from other programs as well as an interactive interface to facilitate
different modeling functions. To use these tools, one needs to: provide
the modeling function, provide the data series, identify a command/call
function to do regression, get the parameters of the functions, remaining
standard error and other regression related outputs, and (in advance of
usage or to fine tune processing) change convergence criterion thresholds
and other limits, e.g., number of iterations. As an alternative, one can
use tools such as Microsoft Excel to do regression analysis by: setting
up parameters for regression, providing initial values for these
parameters, setting up data in a spreadsheet (date, withdrawal) in two
columns, setting up a first column to compute the withdrawal according to
the modeling function (of date, withdrawal and parameters); setting up a
second column to compute error (modeled withdrawal value-observed value)
for each date, setting up a cell to compute root mean square (RMS) of the
error, e.g., as square root of sum of the square of error for each
date/number of dates analyzed, and then using an Excel optimization
function to minimize RMS error while varying parameters.

[0133] While it is generally preferable to perform regression for the
complete modeling function in one step, this may not be possible due to
numerical issues or processing concerns; in such cases the regression may
be performed in a set of steps, e.g. first do regression to estimate
parameters of the linear component and a first periodic function, compute
its parameters, fix those, and repeat the steps above, to compute the
parameters of the 2nd periodic function, regressing on the remaining
error amounts computed.

[0134] Although a goal of regression is to determine the values for the
parameters of the withdrawal modeling function f1 (date) that provide a
low value of standard error, generally it is important to not overfit a
function to data. For example, if there is only data for three (3)
months, one does not have data to be able to model variations by specific
months, e.g., over 6 months and over 12 months. Further, one does not
have withdrawals for each weekday on each day number (1, . . . , 31) of
the month. Thus, in such instance, to produce a reliable model that is
usable for forecasting, one can build a combined model for all weekdays
by using the overall data series and remove corresponding functions from
the modeling function, falldays(date), as follows:

[0136] Thus, for a given data series, FIG. 5 describes the process of
building a model for the data series. The modeling component preferably
operates as follows. For each day of the week, the component builds a
model of a data series representing cash withdrawals. As noted above,
this model preferably is built by single or multiple step non-linear
regression analysis containing several components that are represented by
linear and non-linear functions and variables, in all cases based on
historical withdrawal and auxiliary data.

[0137] In particular, a regression analysis or other function data fitting
process 500 receives, as inputs: a processed data series DSi 502 (such as
generated in FIG. 3), a withdrawal modeling function definition (e.g.,
f(date) above) 502 s and auxiliary data like temperature and snow (if it
is available) 504. The outputs of the process 500 preferably comprise
model parameters 508 and a standard error for the unexplained random
variation 510, which together comprise dataset 512 (the model parameters
and standard deviation of residual).

Using Model for Forecasting

[0138] The system can now forecast cash demand for each date. In
particular, preferably an expected value of the cash withdrawal for a
date, Fcst(date), is determined by plugging the date in the model for the
day of the week for the date. As an example, using the withdrawal
modeling function f, if one needs to forecast withdrawals on Sep. 22,
2005, which is a Thursday, then

[0139] Fcst(Sep. 22, 2005)=fThursday(Sep. 22, 2005)

[0140] In addition, given a desired confidence level CL, such as 0.95 or
95%, the system computes an FcstUL "upper limit value" such that the
likelihood of withdrawals on that date are less than or equal to the
upper limit is given "confidence level" FcstUL(date, CL) as follows:

FcstUL(date,CL)=Fcst(date)+StdErrday of the week(date)*Z(CL)

where Z is such that Prob(x≦Z)=CL, where x is a random variable
with distribution N(0,1), i.e., standard normal distribution.

[0141] It should be noted that:

[0142] Buffer(date, CL)=FcstUL(date, CL)-Fcst(date).

[0143] FIG. 6 illustrates this processing. A dataset 602 (the model
parameters and standard deviation of residual (standard error of
estimate), as generated in FIG. 5) is applied with the desired confidence
level 604 to a computation function 606. An expected value and buffer
values 608 are generated and collected as the model forecast 610.
Essentially, for each date, the forecasting model generates an initial
forecast of expected cash withdrawals. The forecast preferably includes
"upper limit" values, or desired values of buffer amount computed as
above, to achieve one or more desired confidence levels in the forecast.
The forecast of expected withdrawals typically is based on the model for
the day of the week, and the unexplained random variation for the day of
the week.

[0144] While it is possible to re-compute model parameters whenever
additional historical data becomes available for an ATM, it is not
necessary to do so. One can re-compute the parameters at some regular
frequency, e.g., every month and forecast using the existing model, which
was updated in not too distant past.

Making Adjustments for Specified Special Event

[0145] As discussed above, the ATM system operator may know of one or more
events that may occur on specific days that may cause withdrawal demand
to be unusually high or low; special events typically are those that are
not already incorporated in the modeling function as auxiliary variables.
If such special situations have been defined for date, then the initial
forecast for the date computed above may be modified to take into account
the adjustments defined for the special situation (s). Examples of such
adjustments are:

[0150] For a composite multi-day period of several dates, e.g., a load
period, the system can compute a forecast, an expected withdrawal and
upper limit on withdrawal for a given confidence level, by aggregating
the forecasts for individual dates (FIG. 6 and FIG. 7). Preferably, this
aggregation is done using standard statistical techniques of summing up
mean and variances of random variables as follows: if there are n days in
the composite period,

CPEV Composite Period forecast Expected
Value = i = dates in the composite
period EV i = i = dates in the
composite period Fcst ( i ) ##EQU00006## CPBF =
Composite Period Buffer = i = dates in
the composite period Bf i / n = (
i = dates in the composite period
Buffer ( i ) ) / n ##EQU00006.2##

[0151] Thus the amount to be loaded or Composite Period Forecast Upper
Limit is:

CPFcstUL=CPEV+CPBF.

[0152] FIG. 8 illustrates one technique for a composite period of n days.
In this example, note that EVi=Fcst(i) and Bfi=Buffer(i), and
CPBF=Composite Period Buffer.

Adjusting for Bundle Size

[0153] Often, the amount to be loaded into an ATM is generally sent as a
set of bundles of currency, e.g., $1,000 bundles. Thus, the present
invention may adjust load amount to take into account the bundle size,
preferably by rounding up to the bundle size the upper limit CPFcstUL
computed above. Alternate methods are to round down to the nearest
multiple of lower bundle size if the CPFcstUL is very close (say within
10% of bundle size) to the nearest multiple of lower bundle size,
otherwise round up to nearest multiple of bundle size.

[0154] As an example, if bundle size was $1,000 and CPFcstUL computed
above was $21,100, one can round it down to nearest $1,000, which gives
CPFcstUL=$21,000. On the other hand, if CPFcstUL computed above was
$21,300, it may be desired to round up to the nearest $1,000, which gives
CPFcstUL=$22,000. (To keep all numbers consistent, the CPBuffer is
appropriately adjusted.)

Taking into Account Machine Capacity

[0155] When computing an amount of money to be loaded in a machine during
a load period of N days, the CPFcstUL value may be checked against
monetary capacity of the machine. If the machine capacity will be
exceeded, the operator may be warned, load amount will be changed such
that it will be less than or equal to the ATM capacity, and an estimate
of the date for which the load is likely to be sufficient will be
prepared. Relevant equations are analogous to the ones defined later in
the monitoring section and thus are not repeated here for the sake of
brevity.

[0156] As an example, if the ATM capacity is $40,000 and the calculated
load amount for a 14 day period is $41,000, the load amount is reduced to
$40,000 and the operator is notified that the load amount is reduced to
$40,000, down by $1,000 from the optimum load amount of $41,000 and, that
for a given confidence level, it is likely to last for 13 days.

Computing Optimum Load Period Length

[0157] A method to compute demand (mean value, required buffer or upper
limit for given confidence level CL) for a load period of n days was
described above. Given the withdrawal forecast models or functions
discussed earlier, the present invention enables one to compute the
optimum load period length.

[0158] Optimum Load Period Length or optimum number of days between loads
preferably is chosen such that per unit cost of loading ATM is a lowest
among all feasible (upcoming load date, a subsequent feasible load date)
pairs. As an example, given a machine that is loaded on Mondays, with
upcoming load date being Jul. 11, 2005, the subsequent load dates will be
Jul. 18, 2005, Jul. 25, 2005, Aug. 1, 2005, Aug. 8, 2005, and so on.
Thus, a goal here is to identify the load period length out of (for
example) 7 days, 14 days, 21 days and 28 days, for which per unit cost of
loading the ATM will be lowest.

[0159] The following describes a method for computing an optimum number of
days between loads by identifying four parts of the solution:

[0160]
Cost of Loading in a load period

[0161] Per Unit Cost of Loading

[0162]
Computing optimum load period for given load date

[0163] Computing
optimum load period length over a longer duration in which multiple loads
will occur

Cost of Loading in a Load Period

[0164] A total cost to load an ATM during a load period, TCTL, typically
consists of multiple factors including, without limitation:

[0165]
Courier_Cost: cost of sending a courier to the ATM, typically $75/load;

[0166] Cost of borrowing money to load into the ATM, which cost itself
typically is affected by:

[0168] Number of days money is borrowed,
which itself has one or more parts:

[0169] UTD: Number of days Upfront
for money to Transit from Bank to the ATM (number of days between
borrowing the money and it becoming available in the ATM for
withdrawals);

[0170] WDD: WithDrawal Day number in the ATM; for the money
that gets withdrawn on the day of the load WDD=1;

[0171] CBD: Number of
days from money being withdrawn from ATM and the money being credited
back to the ATM operator's account, typically 1 day;

[0172] Amount of
money borrowed (and not just withdrawn): for the first day in the load
period, this is a total amount for the load period and then the value
successively goes down every day as money gets withdrawn; for load period
of length k days beginning on ld_date, let:

[0176] Residual(ld_date,k) (or Residual)=Amount money
expected to be left over at the end of the load period, CPBF computed
above; note that Residual=LA-TMD Then, the total cost of loading for k
days beginning on date ld_date:

[0177] A withdrawal transaction is a natural unit for an ATM, and cost of
money per transaction is an important measure in ATM industry. Given
average amount of money withdrawn per transaction, AWD, the number of
transactions in a load period is then:

NT(ld_date,k)=TMD(ld_date,k)/AWD

If AWD is not available, one can assume AWD=100.

[0178] Thus, per unit cost of loading during a load period of k days
beginning on ld_date is:

PUC(ld_date,k)=TCTL(ld_date,k)/NT(ld_date,k)

[0179] FIG. 9 shows the process of computing cost for a load period of k
days in an illustrative embodiment.

Computing Optimum Load Period Length Given a Load Date

[0180] Note that as the load period length k increases, TCTL(ld_date,k)
increases monotonically but PUC(ld_date,k) does not. PUC first decreases
as the courier cost is amortized over a larger number of transactions,
and it then increases as the interest cost per transaction keeps
increasing, because the money is held for a longer period and the amount
of buffer or residual keeps increasing.

[0181] To compute the optimum load length given the scheduling
constraints, the invention finds k such that per unit cost PUC(ld_date,k)
is the lowest among feasible load days, preferably, using following
procedure:

[0182] 1) Set upcoming load date, ld_date; Set j=0

[0183] 2)
Set j=j+1

[0184] 3) Given scheduling constraints, identify jth
feasible next load date, nld_date (for example, because of courier
schedules, if the ATM is generally scheduled to be loaded only on
Wednesdays, then jth nld_date is jth Wednesday following
ld_date).

[0185] 4) k(j)=nld_date-ld_date

[0186] 5) Compute PUC(ld_date,
k(j)) as shown earlier

[0187] 6) If {(PUC(ld_date, k(j))<PUC(ld_date,
k(j-1)))

[0188] AND (LA(ld_date,k(j))≦ATM_Capacity)} then

[0189] {go to
step 2 to try longer load period}

[0190] Else {optimum load period length n=nld_date-ld_date}.

[0191] As an example, if the PUC were as follows for load period beginning
Jul. 11, 2005:

The algorithm chooses load period of 14 days, with subsequent load being
on Jul. 25, 2005.

[0192] The process is illustrated in FIG. 10.

Computing Optimum Load Period Length Given a Period During which Multiple
Loads Will Occur and Scheduling Constraints

[0193] Often, an ATM operator needs to tell the courier a month or more in
advance the load schedule for each ATM. The present invention achieves
this goal as follows:

[0194] 1) Given starting date for establishing the
new schedule, start with the first load date and successively compute
optimum load period length for it and the next load date;

[0195] 2) If a
fixed load period length is desired, then, take an average of the load
period lengths obtained in step 1 above, and if the load can occur only
at certain frequency, round it up or down to closest feasible frequency
(e.g., 1 week, 2 weeks, and so on).

[0196] 3) If it is possible to change
the weekday of the load, pick the day before the weekdays that has a
highest average withdrawal.

Monitoring to Prevent Runouts in the Current Load Period

[0197] Once an ATM has been loaded with money, the system preferably
monitors it on an on-going basis. When data for withdrawal on date "date"
arrives, preferably, the system not only checks it for exceptions, but
also determines the remaining balance in the ATM and whether it will be
sufficient to support withdrawals in the remaining part of the current
load period.

[0198] The invention uses the forecast information computed when the load
amount was determined and recent withdrawal information to estimate the
remaining balance in the ATM and its sufficiency.

Let:

[0199] currlddate: Load date for the current load period

[0200] N: the
length of the current load period

[0201] lwdate: date for which the
latest withdrawal data just arrived;

[0202] L: the number of remaining
days in the current load period;

[0203] P: the number of days already
past in the current load period; therefore, the dates

[0204] for the days
in the load period that are already past are currlddate, . . .
currlddate+P-1;

[0205] WD(d): the amount withdrawn on date d;

[0206]
EODBAL(d): remaining balance in ATM at the end of the date d;

[0207]
PDAct: Actual withdrawals during past days of the current load period;

[0208] PDFcst: Expected value of forecasted withdrawals during past days
of the current load period;

[0209] PDFcstUL: Expected upper limit on
forecasted withdrawals during past days in the current load period;

[0225] d) determine a date that
the system would expect the remaining money to last with a given
confidence level:

TABLE-US-00004

[0225] If (RResidualLL < 0) {
/* ATM does not have enough money left to meet the upper limit
on demand */
/* Find k, number of days up to which the remaining amount will
be sufficient */
Find k, k between 0 and L-1, such that estimated Lower Limit on
Residual after k
days is >= 0 and is <0 on k+1 day, where
kDFcst = Σl=1,...,k Fcst(lwdate+l)
kDFcstUL = kDFcst + (Σl=1,...,k FcstUL(lwdate+l) - kDFcst)/ k
If (PDFcstUL < PDAct) then {
kDFcst = kDFcst * PDAct/PDFcstUL
kDFcstUL = kDFcst * PDAct/PDFcstUL
}
kResidualEV = EODBAL(lwdate) - kDFcst
kResidualLL = EODBAL(lwdate) - kDFcstUL
/* Note that this computation was already done for k=L and the desired
value can be done simply by first computing the above for k=L-1
and keep decreasing k until the condition is met. */
}
Else {
/* ATM has enough money left to meet the upper limit on demand */
/* Find k, number of days up to which the remaining amount will
be sufficient */
Find k, k ≧ L, such that estimated Lower Limit on Residual after
k days is >= 0 and is <0 on k+1 day where:
kDFcst = Σl=1,...,k Fcst(lwdate+l)
kDFcstUL = kDFcst + (Σl=1,...,k FcstUL(lwdate+l) - kDFcst)/ k
If (PDFcstUL < PDAct) then {
kDFcst = kDFcst * PDAct/PDFcstUL
kDFcstUL = kDFcst * PDAct/PDFcstUL
}
kResidualEV = EODBAL(lwdate) - kDFcst
kResidualLL = EODBAL(lwdate) - kDFcstUL
/* Note that this computation was already done for k=L and the desired
value can be done simply by first computing the above for k=L+1
and keep increasing k until the condition is met. */
}

[0226] 5) Notify user of the EODBAL, expected value of additional
withdrawals till the end of the current load period (RDFcst), upper limit
on additional withdrawals till the end of the current load period
(RDFcstUL), and estimate of the date on which there is a possibility that
the machine can run out, date+k,

[0227] Once the analysis has been done on a given (e.g., recent) arrival
of withdrawal data, the operator can make a mid-course correction, e.g.,

1) Compute an emergency load amount and order an ATM load; and/or 2)
Delay a next planned load.

Variants

[0228] The following section describes some of the other capabilities or
variations that may be included in the inventive system:

Dealing with Multiple Denominations

[0229] The following approaches may be used:

[0230] a) Build separate
model for each denomination, or

[0231] b) Build model for the aggregate
amount and a relative distribution of different denominations. Dealing
with Add/Swap

[0232] Further, if the loading process requires that the load amount is
added to the money that may already be present in the ATM at the loading
time, rather than swapped with the money remaining in the ATM at the time
of load, the system can adjust the load amount to take into account the
expected minimum value of the money already expected to be in the ATM
when the load is performed. An illustrative way to do make the adjustment
is as follows:

[0233] estimate mean and standard deviation of the
random variable corresponding to the amount remaining in the ATM at the
load time using similar computations (see monitoring steps described
earlier),

[0234] define a new random variable (r.v.) corresponding to
required amount to be loaded=r.v. representing withdrawals during the
composite period-r.v. corresponding to the amount remaining in the ATM at
the load time,

[0235] estimate mean and variance of this new random
variable using the standard statistical techniques,

[0238] It should also be noted that the there is no other additional
"Transit Time" for this money and the interest cost of this money is
appropriately computed.

Recycling of the Deposited Money

[0239] It may also be desirable to forecast as a function with respect to
recycling of the money that has been deposited by a customer in an ATM.
In this alternative, the system forecasts the expected value of the money
to be deposited instead of an upper limit and lower limit (for given
confidence level) of the money to be deposited. The system may further
forecast the expected value of the recyclable money instead of upper
limit, lower limit (for given confidence level) of the recyclable money.
Preferably, the system also monitors this amount on a given, periodic
basis. Load size may also be reduced appropriately as the interest rate
for the recycled money may be different from the non-recycled or borrowed
money.

Managing a Multi-ATM Site

[0240] This system and method are easily adapted to manage a multi-ATM
site. For example, one can construct the data series for the entire ATM
site by simply adding the withdrawals for each of the ATMs for every day
to obtain total withdrawals at the site. The remaining balance at each of
the ATMs can also be accumulated and used in the forecasting process. A
prediction then is done for the total site in the manner previously
described. The load amounts are then distributed to individual ATMs in
proportion to their capacity.

Computing Optimum Confidence Level

[0241] Rather than arbitrarily choosing a confidence level, the system can
further optimize the loading process to reduce overall cost by taking
into account the cost of ATM run out. This cost can be defined, for
example, as a minimum of:

[0242] Cost of reloading the ATM, which
includes emergency courier costs, cost of borrowing money, administrative
costs, and the like; this cost can be reduced if a next load can be
cancelled and combined with this emergency load, and

[0243] Cost of not
replenishing the ATM, which includes lost revenue in terms of lost
transaction fees and loss of goodwill.

Construction of the Modeling Function

[0244] One of ordinary skill will appreciate that there are several
variations that are easily conceptualized on the modeling function and
data aggregation. A few of these are outlined below.

Periodic functions:

[0245] (a) Frequencies may also be automatically
determined

[0246] (b) For each period, higher harmonics for periodic
functions are included (as in Fourier series), rather than one cosine and
sine function at each period.

[0246] FSN(x,p)=Σi=1, . . .
,N(ai*cos(2*π*x/p)+bi*sin(2*π*x/p))

[0247] It can be
seen that having functions with periods of 1 year, 6 months and 3 months
is equivalent to having 3 harmonics of a Fourier Series with period of 1
year.

[0248] (c) Cosine or sine functions are included with phase shift,
rather than a combination of cosine and sine functions, i.e., a function
in the form of a*sin(2*π*date/pd-ph) may be considered equivalent to a
function in the form of wc*cos(2*π*date/pd)+ws*sin(2*π*date/pd)
Non-periodic functions

[0249] .sup.(a)Other non-periodic functions may be
included in the modeling function, e.g., log(date)

[0250] .sup.(b)Rather
than having binary valued functions, one can have multi-valued functions
for factors.

[0251] .sup.(c)Additional factors may be added to the
function.

Other Ways to Define Data Series

[0252] As described above, the incoming withdrawal data was separated into
defined independent data series by day of the week. The method applies
equally well even in situations where it is appropriate to define data
series in a different way, e.g., one may have a different data series,
e.g., M-Th (non-Friday weekdays), F, and S-S (weekend), or the like. This
alternative approach can reduce computation and storage requirements.

[0253] Also, if one is interested in only obtaining forecasts for fixed
granularity, such as multiple of weeks, one can create aggregate data
series in which each data element contains the sum of withdrawals for
constituent days. Individual sub-functions within f(weeknum) have to be
appropriately defined.

Predicting at Finer Granularity than Day

[0254] If the prediction is required for a finer granularity, say by shift
or by hour, one can collect withdrawal data at that granularity and then
either:

[0255] a) Create data series at this granularity (e.g., by
hour) and adjust the modeling function accordingly to include day of the
week as a variable, or

[0256] b) Create data series at day of the week
granularity as before and adjust the modeling function to include
variable corresponding to desired granularity, e.g., ishour(date, i).

[0257] Then, the prediction can be analyzed according to the methods
discussed earlier.

A Method of Lowering Standard Error of Estimate for Multi-Day Periods

[0258] It is possible that the model for weekly withdrawals (base
aggregate period=week) may have relatively less random variation than an
aggregate of the models for each day of the week (individual data
series), i.e.,

Std--Err(Weekly Model)<Standard Error of the Aggregate of
Weekday Models

In such event, when forecasting demand for a multi-day period of
size≧week, the system can construct a modeling function using
weekly withdrawal data series (as discussed earlier) and compare its
Standard Error of Estimate to that of an aggregate of the day of the week
models and select the one that is better.

[0259] The present invention provides numerous advantages over the prior
art. It particular, this invention provides a novel method and apparatus
for forecasting cash demand for ATM or any other cash dispensing device,
reliably developing ATM load schedules and monitoring the funds in the
ATM to determine the likelihood of fund depletion before a next load.
This invention enables ATM operators to optimize their operations taking
into account key variables affecting operation. Examples of such
variables include, but are not limited to, the constraints on when
machines can be loaded, machine capacity for holding cash in different
denominations, acceptable likelihood of cash being run out, interest
rates, money transit times, cost of loading cash, and the like. The
invention is a self-learning system in that it automatically configures
itself from the withdrawal data for each ATM separately.

[0260] While the above describes a particular order of operations
performed by certain embodiments of the invention, it should be
understood that such order is exemplary, as alternative embodiments may
perform the operations in a different order, combine certain operations,
overlap certain operations, or the like. References in the specification
to a given embodiment indicate that the embodiment described may include
a particular feature, structure, or characteristic, but every embodiment
may not necessarily include the particular feature, structure, or
characteristic.

[0261] While the present invention has been described in the context of a
method or process, the present invention also relates to apparatus for
performing the operations herein. This apparatus may be specially
constructed for the required purposes, or it may comprise a general
purpose computer selectively activated or reconfigured by a computer
program stored in the computer. Such a computer program may be stored in
a computer readable storage medium, such as, but is not limited to, any
type of disk including optical disks, CD-ROMs, and magnetic-optical
disks, read-only memories (ROMs), random access memories (RAMs), magnetic
or optical cards, or any type of media suitable for storing electronic
instructions, and each coupled to a computer system bus.

[0262] While given components of the system have been described
separately, one of ordinary skill will appreciate that some of the
functions may be combined or shared in given instructions, program
sequences, code portions, and the like.

[0263] While the above-identified subject matter has been described in the
context of an ATM environment, the invention may be practiced in other
types of environments such as, without limitation, any situation where it
is desirable or necessary to determine supply requirements for any goods
(or services) whose demand varies periodically and randomly in complex
ways. Thus, for example, this invention is applicable to any other
situation where one needs to determine of supply cash, e.g., the amount
of money needed for a teller for a bank. Furthermore, this invention
provides a novel method for determining time varying expected value,
variation in the value and the limit on the maximum amount of the value
for given confidence for any set of metrics derived from physical
systems.

[0264] In addition to or as an adjunct to the dispenser machines
themselves, the invention may be implemented within the context of a
distributed computing environment that includes a set of
computing-related entities (systems, machines, processes, programs,
libraries, functions, or the like) that facilitate or provide the
above-described functionality. A representative computer is a client
workstation or a network-based server running commodity (e.g.,
Pentium-class) hardware, an operating system (e.g., Linux, Windows 2000,
OS-X, or the like), an application runtime environment (e.g., Java), and
a set of applications or processes (e.g., applets, servlets, linkable
libraries, native code, or the like, depending on platform) that provides
the functionality of a given system of subsystem. Conventional
network-based access protocols and techniques (e.g., HTTP, SOAP, RPC, and
the like) are supported. The method may be implemented as a standalone
product, or as a managed service offering. Moreover, the method may be
implemented at a single site, or across a set of locations. All such
systems, methods and techniques are within the scope of the present
invention.

[0265] One of ordinary skill will appreciate that the principles of the
present invention have general applicability beyond ATM cash forecasting.
Indeed, the techniques described herein are applicable to a broad class
of problems where one needs to determine the future behavior on the basis
of past behavior and come up with optimum solutions. For ease of
explanation, the preferred embodiment of the invention is described in
the context of determining future withdrawals at an ATM and optimizing
the amount of funds (cash, items representing cash, or the like) to be
loaded and load schedule for given parameters.