Media replenishment management

Abstract

A method of method of managing media replenishment at a media terminal, the method comprising: receiving a media event from a media terminal; retrieving a next scheduled media replenishment event for that media terminal; evaluating if the next scheduled media replenishment event is scheduled to occur within an acceptable delay period; and initiating an unscheduled replenishment event only if the next scheduled media replenishment event is scheduled to occur after the acceptable delay period.

Claims

1. A method of managing media replenishment at a media terminal, the method comprising: receiving, by executable instructions that execute on a processor of a server from a non-transitory computer-readable storage medium, media total updates relating to a media terminal including denomination totals for each denomination in the media total updates, wherein receiving further includes determining from the media total updates cassette totals for each media cassette of the media terminal; calculating, by the executable instructions, a time at which a media total at the media terminal is expected to fall below an acceptable threshold based on the media totals and media demands for the media terminal in previous replenishment cycles associated with the media terminal and based on an acceptable delay period added to the calculated time, the acceptable delay period including: a lead time for media delivery to the media terminal, a geographic spread of a network that includes the media terminal and other media terminals, and a length of time necessary to travel from a media vault location to the media terminal; ascertaining, by the executable instructions, if a next scheduled replenishment event for that media terminal will occur before that calculated time; changing, by the executable instructions, a time of the next scheduled replenishment event ensuring a changed time occurs before that calculated time; issuing, by the executable instructions, a replenishment request to the media vault based on the changed time; updating, by the executable instructions, a Graphical User Interface (GUI) with information for the media terminal based on the replenishment request; presenting, by the executable instructions within the GUI, an accuracy of media replenishment that reflects forecasted media demands for the media terminal versus actual media usage for the media terminal as one of: a line graph, a bar chart, and traffic lights; and providing, by the executable instructions through the GUI, a manual override that permits an authorized user of the GUI to request replenishment of the media terminal and the other media terminals at any time.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) FIG. 1 is a simplified block diagram illustrating a system for managing media replenishment according to one embodiment of the present invention;

(2) FIG. 2 is a flowchart illustrating steps performed by the media terminal manager of FIG. 1 in creating a media replenishment schedule for media terminals (ATMs) in the system of FIG. 1;

(3) FIG. 3 is a pictorial diagram illustrating a graphical user interface provided by the media terminal manager of FIG. 1; and

(4) FIG. 4 is a flowchart 70 illustrating steps performed by the media terminal manager in evaluating if media replenishment is required in response to a media event received from one of the media terminals (ATMs) of FIG. 1.

DETAILED DESCRIPTION

(5) Reference is first made to FIG. 1, which is a block diagram illustrating a system (or network) 10 for managing media replenishment (in particular cash replenishment) according to one embodiment of the present invention.

(6) The system 10 comprises a plurality of media terminals 12 (only three of which are illustrated in FIG. 1) in the form of automated teller machines (ATMs) coupled to a remote media terminal manager (in this embodiment, an ATM manager) 14 by an Internet Protocol (IP) network 16.

(7) The ATM manager 14 comprises four main components: (i) an event manager application 18 operable to receive events from the plurality of ATMs 12; (ii) a replenishment manager application 20 operable to schedule cash replenishment operations for the ATMs 12; (iii) a replenishment dispatcher application 22; and a graphical user interface (GUI) 24.

(8) In this embodiment, the three applications are located on the same server (the ATM manager 14); however, in other embodiments, the three applications may be located on two or three different servers and may be coupled by one or more networks.

(9) The event manager application 18 is similar to the NCR APTRA Vision application, available from NCR Corporation. The event manager application 18 is used to monitor the status and performance of the ATMs 12 in the system 10, and to manage incidents at the ATMs 12 by dispatching customer engineers respond to those incidents.

(10) Each of the ATMs 12 may be configured with a management agent, such as the Unified Agent (trade mark), available from NCR Corporation, to interface with the event manager application 18.

(11) The replenishment manager application 20 implements cash optimization algorithms and functions. In this embodiment the replenishment manager application 20 is similar to the NCR APTRA OptiCash (trademark) software, available from NCR Corporation.

(12) NCR APTRA OptiCash software provides an advanced cash management solution that predicts the demand for currency at each media terminal (or other cash point), such as the ATMs 12, on an individual basis. By applying sophisticated mathematical algorithms to historical, event and cost data, the optimum cash position and delivery schedule for each ATM 12 (or each currency cassette or cash drawer within an ATM 12) is determined.

(13) The system 10 also comprises a conventional transaction switch 30 and an authorization server 32 (also referred to as a transaction host or an authorization host). As is known in the art, the transaction switch 30 is used to route transactions requested by a customer at one of the ATMs 12 to a financial institution that maintains an account for that customer.

(14) The authorization server 32 also stores account information for all of the customers of the financial institution that owns or operates the system 10, and also stores information about each ATM 12 (such as the cash totals, total amount dispensed since last replenishment, and the like). In this embodiment, the transaction switch 30 and the authorization server 32 are conventional, unmodified, devices similar to those currently used in conventional ATM networks.

(15) The event manager application 18 may receive information and events directly from the ATMs 12 and/or from the transaction switch 30 (broken line 33 in FIG. 1 illustrates this communication).

(16) A media replenisher 34, in the form of a cash-in-transit (or CIT) person, is illustrated in a vehicle that conveys currency from the currency vault (also referred to as a CIT center, a cash vault, or a bullion center) 36 to the ATMs 12 in response to a cash replenishment request issued by the replenishment dispatcher application 22 (as will be described in more detail below).

(17) The replenishment dispatcher application 22 is operable to issue cash replenishment requests to the CIT center 36 according to a defined schedule (scheduled cash replenishments) or in response to the ATM 12 running low or out of cash (unscheduled cash replenishments). However, in this embodiment unscheduled cash replenishments are only issued automatically if certain criteria are met (or manually if a human activates a manual override option), as will be described in more detail below.

(18) The media replenisher 34 and the currency vault 36 are not part of the system 10 but provide replenishment services thereto. The currency vault 36 may provide cash to multiple systems 10 (for example, different ATM networks operated by different financial institutions).

(19) Reference will now also be made to FIG. 2 and FIG. 3. FIG. 2 is a flowchart 50 illustrating steps performed by the ATM manager 14 in creating a cash replenishment schedule. FIG. 3 is a pictorial diagram illustrating the graphical user interface 24. As used herein, a cash event is an event that indicates that one of the ATMs 12 (or part of the ATMs 12, such as one currency cassette) will need replenishment with cash. Examples of cash events are cash low events, cash empty events, and the like.

(20) Initially, the replenishment manager application 20 accesses cash amount information for each of the ATMs 12 and any other cash terminals (such as assisted teller terminals) in the network 10 (step 52). This cash amount information may be stored by the event manager application 18 in a shared area accessible by both the event manager application 18 and the replenishment manager application 20. Alternatively, the replenishment manager application 20 may send a request for this information to the event manager application 18 across a defined interface 38.

(21) The replenishment manager application 20 also accesses any unscheduled replenishment information relating to the ATMs 12 (this will be described in more detail with reference to FIG. 4 below) (step 54). This enables the replenishment manager application 20 to take account of any unscheduled replenishments initiated but not yet completed.

(22) Taking all of this accessed information into account (in addition to other information, such as the time of year, currency demands in the previous replenishment cycles, and the like) the replenishment manager application 20 then calculates when each ATM 12 needs to be replenished with cash and how much cash is needed for each ATM 12 (step 56).

(23) The replenishment manager application 20 then creates a cash replenishment schedule that includes the cash replenishment details calculated in step 56 (step 58) and communicates the cash replenishment schedule to the replenishment dispatcher application 22 (step 60).

(24) The replenishment manager application 20 also populates the GUI 24 with details of the scheduled cash replenishment (step 62).

(25) The GUI 24 displays a street map 40 of the vicinity of the ATMs 12 in the network 10. The GUI 24 also displays an icon 42a,b,c for each ATM 12a,b,c representing the physical location on the map of each ATM 12. Each icon 42 is colored to indicate the status of that ATM 12. When a user of the GUI 24 hovers over or clicks on different parts of the ATM icons 42 additional information (shown by text boxes 44 and 46 in FIG. 3) is displayed that is relevant to that ATM 12. This additional information includes the cash status of that ATM (high, medium, or low amount of cash remaining) details of the next scheduled replenishment (from the cash replenishment schedule) (shown in box 44) and details of events received relating to that ATM 12 (shown in box 46). If there is currently an incident at that ATM 12 (for example, the ATM is out of service) then details of the incident are also provided. It will be appreciated that numerous different graphical formats may be provided to convey information relating to the ATMs 12.

(26) As new cash totals are received from each ATM 12, the event manager application 18 updates the GUI 24 so that the current cash totals are shown. Similarly, the event manager application 18 updates the GUI 24 if any incident is received relating to one of the ATMs 12. These activities of the event manager application 18 updating the GUI 24 occur in parallel with the flow 50 described above.

(27) Reference will now be made to FIG. 4, which is a flowchart 70 illustrating steps performed by the ATM manager 14 in evaluating if cash replenishment is required in response to a cash event received from one of the ATMs 12.

(28) The event manager 18 is configured to receive events created by the ATMs 12 (step 72).

(29) If a cash event (that is, an event relating to cash being low or empty in an ATM or a currency cassette within an ATM) from one of the ATMs 12 is received by the event manager application 18, which could occur at any time, then the ATM manager 14 ascertains if cash replenishment is needed to prevent the ATM 12 going out of service (step 74). An example of when cash replenishment may not be needed is if there are four currency cassettes in the ATM 12, and only one of them has reached a cash low condition and the other three cassettes are well stocked with cash, then a cash replenishment operation may not be required.

(30) If replenishment is not needed, then the ATM manager 14 updates the GUI 24 to indicate that the cash event has been processed (so that a user of the GUI 24 does not manually trigger a cash replenishment dispatch operation) but the ATM manager 14 does not trigger an unscheduled cash replenishment (step 76).

(31) If replenishment is needed, then the ATM manager 14 retrieves a next scheduled cash replenishment event for that ATM 12 (step 78).

(32) The ATM manager 14 then evaluates if the next scheduled cash replenishment event is scheduled to occur within an acceptable delay period (step 80). The acceptable delay period can be configured based on multiple parameters, for example: the lead time for cash delivery, the geographic spread of the network, how long it will take to travel from the vault 36 to an ATM 12, the current demand for cash at that ATM 12 or in the network 10 as a whole, the time at which the cash event occurs, and the like. In this example, the acceptable delay period for the combination of the ATM 12 that triggered the cash event and the time at which the cash event occurred is four hours.

(33) If the next scheduled cash replenishment event is scheduled to occur within the acceptable delay period (in this example, in less than four hours from when the cash event was received), then the ATM manager 14 updates the GUI 24 to indicate that the cash event has been processed (so that a user of the GUI 24 does not manually trigger a cash replenishment dispatch operation) but the ATM manager 14 does not trigger an unscheduled cash replenishment (step 82).

(34) If the next scheduled cash replenishment event is not scheduled to occur within the acceptable delay period (in this example, if the next scheduled cash replenishment event is more than four hours from when the cash event was received), then the ATM manager 14 (in particular, the replenishment manager application 20) calculates the amount that should be provided to replenish the ATM 12 that triggered the cash event, and also decides if other ATMs 12 should also be replenished (which may enable a scheduled cash replenishment operation to be cancelled) (step 84).

(35) The ATM manager 14 (in particular, the replenishment dispatcher application 22) then issues a replenishment request to the currency vault 36 for an unscheduled cash replenishment (referred to herein as a qualified unscheduled cash replenishment) and updates the GUI 24 to indicate that an unscheduled cash replenishment has been initiated (including details of the unscheduled cash replenishment) (step 86). This may involve updating the details of multiple ATMs 12 on the GUI 24 if more than one ATM 12 is to be replenished as part of the unscheduled replenishment.

(36) The details of the unscheduled cash replenishment include when the replenishment is expected to occur, the amount of cash to be replenished (including the amount and denomination for each currency cassette), the name of the replenishment company, and the like. In this embodiment, the replenishment request is issued by sending an electronic communication to the vault 36.

(37) The replenishment dispatcher application 22 monitors for confirmation of receipt of the dispatch instructions to ensure that the replenishment request was received by the currency vault 36.

(38) The GUI 24 may also display the accuracy of the replenishment manager application 20 by depicting the forecasting cash demand and the actual cash usage (as indicated by the cash counts received from the ATMs 12) in any convenient manner (such as a line graph, a bar chart, traffic lights, or the like). The ATM manager 14 may provide this depiction in the format of a report that can be emailed to authorized users who may have an interest in monitoring the performance of the replenishment manager application 20.

(39) The replenishment manager application 20 may monitor cash counts received by the event manager application 18 and may modify the scheduled cash replenishment operations to take account of actual cash demand in the network 10 rather than just relying on predicted cash demand. This may enable the network 10 to avoid using unscheduled replenishment operations by increasing the frequency of scheduled replenishment operations in response to a higher than predicted demand for cash.

(40) The ATM manager 14 may also provide a manual override facility that allows an authorized user of the GUI 24 (having sufficient privileges to make such a request) to request replenishment of any of the ATMs 12 at any time.

(41) It should now be appreciated that this embodiment has the advantage of requiring fewer unscheduled (emergency) cash replenishments, which are typically much more costly than scheduled cash replenishments. Where an unscheduled replenishment is required, the amount and denominations used can be optimized by the replenishment manager application 20 and integrated into the scheduled replenishment cycle.

(42) Various modifications may be made to the above described embodiment within the scope of the invention, for example, in other embodiments, media terminals other than ATMs, or networks other than SSTs (for example, point of sale (PoS) terminal networks, assisted service terminal networks, mixed PoS, assisted service, and ATM networks, or the like), may be used to implement the media count management function.

(43) In other embodiments, media other than, or in addition to, cash, for example, stamps or tickets, may be replenished.

(44) In other embodiments, the ATM manager 14 may be incorporated into the transaction switch 30 or the authorization server 32.

(45) The steps of the methods described herein may be carried out in any suitable order, or simultaneously where appropriate. The methods described herein may be performed by software in machine readable form on a tangible storage medium or as a propagating signal.

(46) The terms comprising, including, incorporating, and having are used herein to recite an open-ended list of one or more elements or steps, not a closed list. When such terms are used, those elements or steps recited in the list are not exclusive of other elements or steps that may be added to the list.

(47) Unless otherwise indicated by the context, the terms a and an are used herein to denote at least one of the elements, integers, steps, features, operations, or components mentioned thereafter, but do not exclude additional elements, integers, steps, features, operations, or components.

(48) The presence of broadening words and phrases such as one or more, at least, but not limited to or other similar phrases in some instances does not mean, and should not be construed as meaning, that the narrower case is intended or required in instances where such broadening phrases are not used.

(49) Features, integers, characteristics or groups described in conjunction with a particular aspect, embodiment or example of the invention are to be understood to be applicable to any other aspect, embodiment or example described herein unless incompatible therewith. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of the features and/or steps are mutually exclusive.

(50) The reader's attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.