Vault Management Method and System

The present invention relates to a vault management system for a cash processing centre. In particular, the present invention relates to systems and methods of efficiently transferring articles of value within a cash processing centre and providing comprehensive audit information.

The management of cash and other articles of value is vital for the functioning of a healthy modem economy. Often the processing and management of cash and other articles of value is unseen by the consumer yet plays an important role in a variety of sectors including retail, banking, gaming, and government. Most forms of management involve controlling and securing the circulation of cash, such as banknotes and coins, and other articles of value such as cheques, tokens or bonds.

The circulation of cash is typically centred on the secure deposit and storage of quantities of currency. This process is typically performed at one or more secure storage areas or vaults. These vaults may be a safe or physically secure building. Cash and other articles of value are deposited into a vault and then subsequently retrieved from the vault when required. Each vault may be owned and managed by a bank or cash management company. The vault is typically integrated into a larger cash processing centre which is further responsible for handling and verifying cash deposits and preparing cash withdrawals for delivery to customers. A cash processing centre will operate in association with cash in transit (CIT) organisations which are responsible for the security of the cash to and from the centre.

For example, a large retail establishment, at the end of a period of trading, will typically accrue a quantity of cash and other articles of value through retail transactions. As it is impractical and unsafe to keep this cash on the retail premises the cash will typically be sent to a cash processing centre, such as a bank or central deposit, using a CIT operator. The cash processing centre is then responsible for receiving the cash from the CIT operator and storing it in a safe location. Once the quantities of cash have been verified and stored, the

verified total of the deposited cash may be credited to the bank account of the retail establishment. In a similar manner, at the beginning of a period of trading, a retail establishment may order a certain quantity of cash to stock the tills or points of sale. This cash will typically be provided by a suitable cash processing centre nearby. At a time stipulated by the cash order the required quantity of cash will be retrieved from the vault and sent to the retail establishment using a CIT operator. Once the cash has been retrieved from the vault and verified it may then be debited from the bank account of the retail establishment. The same processes are also used by high street banks and post offices.

When operating a cash processing centre there are several inherent problems. The first of these is the difficulty in keeping track and control of all the deposits and orders that flow through the vault. For example, a medium to large cash deposit centre may hold thousands if not millions of pounds in a vault at any one time. With such large quantities of cash it is very easy for orders and deposits to be lost or for cash to be stolen by unscrupulous employees or malicious parties. As the cash processing centre would be liable to pay out for any shortfalls in cash amount there is thus a requirement to keep track of all deposits and to prevent theft and loss.

A second problem that arises when dealing with cash processing, and which especially arises with large quantities of cash, is how to process deposits and orders in the quickest possible time. Quick processing is essential in order to prevent cash shortages in the customers requiring cash and also to prevent backlogs within the cash processing centre itself. Many cash processing centres are often constrained by the hours of opening of modern retailers and banks. For example, it is preferable for customers to send cash amounts for deposit after closing in the evening and receive cash orders before opening in the morning. Additionally, much cash processing occurs when customers are closed on the weekend. Hence there is a requirement to quickly perform a deposit and process cash orders within the cash processing centre, not only to reduce costs, but to keep the supply of cash fluid.

W

3

A third problem when dealing with cash processing in a cash processing centre is how to efficiently manage a large number of transactions whilst minimising the cash held on site. Modern large cash processing centres can receive hundreds of orders and hundreds of deposits every day requiring large amounts of 5 available stock. If a large stock is required this will increase the attractiveness of the centre to thieves as well as require large amounts of space to be physically secured.

Unfortunately, most cash processing centres involving a vault operated using 10 antiquated technology and procedures which are not able to address the above problems and are not able to keep up with the demands of a modern economy.

According to a first aspect of the present invention there is provided a method of auditing one or more articles of value within a cash processing centre, the 15 method comprising: assigning ownership of the one or more articles of value to a first entity; recording the assignment of ownership in a database; transferring ownership of the one or more articles of value to a second entity; and updating the database to record the change in ownership to the second entity.

20 Several examples of a number of methods and systems according to the present invention will now be described with reference to the accompanying drawings, in which:-

Figure 1A is a process diagram of an exemplary cash processing cycle 25 according to a first embodiment of the present invention;

Figure 1B is a process diagram of an exemplary extended cash processing cycle according to a second embodiment of the present invention;

30 Figure 1C is a schematic diagram of an exemplary cash processing centre configured to implement the first embodiment of the present invention;

Figure 1D is a schematic diagram of an extended exemplary cash processing centre configured to implement the second embodiment of the present invention;

Figure 1 E is a schematic diagram of an alternative extended exemplary cash processing centre configured to implement the second embodiment of the present invention;

Figure 2A is a diagram illustrating an exemplary hardware configuration for implementing the first embodiment of the present invention;

Figure 2B is a diagram illustrating an exemplary hardware configuration to implement the fourth embodiment of the present invention;

Figure 3A is a flow chart demonstrating an exemplary transfer process according to the first and second embodiments of the present invention;

Figure 3B is a flow chart demonstrating an exemplary acknowledgement process according to the first and second embodiments of the present invention;

Figure 4 is a flow chart demonstrating an exemplary cash reception process according to the second embodiment of the present invention;

Figure 5A is a flow chart demonstrating an exemplary cash deposit operation according to a first embodiment of the present invention;

Figure 5B is a flow chart demonstrating an exemplary count operation according to a first embodiment of the present invention;

Figure 6 is a flow chart demonstrating an exemplary cash order processing operation according to a first embodiment of the present invention;

Figure 7 is a flow chart demonstrating an exemplary cash despatch operation according to the second embodiment of the present invention;

Figure 8 is a diagram illustrating an exemplary hardware configuration of a third embodiment of the present invention;

Figure 9 is a flow chart demonstrating an exemplary deposit processing operation according to a fourth embodiment of the present invention;

Figure 10 is a diagram illustrating an exemplary currency sorting machine for implementing the exemplary deposit processing operation of Figure 9; and

Figure 11 is a diagram illustrating a typical stack of banknotes used in the exemplary deposit processing operation of Figure 9.

Figure 1A displays a number of processes involved in the management of a vault within a cash processing centre according to a first embodiment of the present invention. The cash processing cycle 100 therein is configured to complement the typical physical layout of a cash processing centre. The cash processing centre may be run by a variety of organisations. These include central banks, commercial banks, cash in transit (CIT) companies and transport and leisure companies. A schematic diagram of the ground plan of an exemplary cash processing centre is shown in Figure 1C. This ground plan is provided as an example only and other differing cash processing centre designs may also be used with the management processes of the present invention. Cash deposit centre 105 comprises secure vault area 121, deposit area 111 and order processing area 131. The secure vault area 121 may comprise, but is not limited to, a safe, a physically secure room or a physically secure area. The deposit area 111 is an area for preparing cash for deposit into the vault and the order processing area 131 is an area for preparing cash orders. The deposit area 111 and the order processing area 131 are separated from the vault area 121 by a physical boundary 141. Physical boundary 141 has two respective openings: entry point 116 into the vault area 121 and exit point 126 into the order processing area 131. These entry and exit points may be provided by one way doors or other suitable secure gateway apparatus. Deposit area 111 may

also be separated from order processing area 131 by physical boundary 142, although in some implementations the two areas may comprise a single room.

The cash processing cycle 100 has three processes that are typically performed in the three respective areas of Figure 1 C. However, it is possible that all three processes may be carried out within the secured boundary of the vault. The cash processing cycle 100 first comprises deposit processing 110. This step is typically performed in the deposit area 111, wherein cash and other articles of value are prepared for deposit into the vault or secure area 121. This preparation may involve: unloading cash from containers; counting, verification and validation; and preparing the cash in a suitable form for deposit, such as bundling the notes in set quantities of denominations. The articles for deposit may comprise articles of value such as coins, banknotes, cheques, tokens or bonds. The flow of cash into vault is illustrated by arrow 115. This represents the physical passage 117 of cash from the deposit area 111 to the vault 121 via entry point 116. Boundary line 140 represents a figurative boundary between the stage of deposit processing 110 and the vault processing 120. Boundary line 140 may reflect the physical boundary 141 between the deposit area 111 and the vault 120 or may simply be a means of delimiting the two processes. The figurative boundary is used as part of the transfer process described in relation to Figure 3.

The cash processing cycle 100 next comprises vault processing 120. At this stage cash received by the vault 121, for example via entry point 116, may be further counted, verified and validated and placed in bundles of denominations suitable for storage. The vault 121 may comprise one or more cash deposit apparatus such as a TCR (Teller Cash Recycler) Twinsafe or "Vertera" (TM) apparatus supplied by De La Rue International. Alternatively, the vault 121 may comprise a regular safe or vault, wherein documents of value are routed in and out of the safe or vault by hand. In this case vault processing 120 may involve depositing received cash into a suitable deposit apparatus. Cash remains in the vault 121 until it is required to fulfil a cash order. At this point the vault processing 120 involves preparing the required amount of cash to send for order processing 130. The flow of cash from the stage of vault processing 120 to the

stage of order processing 130 is represented by arrow 125 and again involves the crossing of figurative boundary 140. This transfer 125 may reflect the physical removal 127 of cash from a safe or secure area 121 via exit point 126 and the transfer of this cash across physical boundary 141 to the order processing area 131.

The third stage of the cash processing cycle 100 is order processing 130. At this stage, quantities of cash are prepared to supply customers, such as, amongst others, retailers and banks. A cash order may be scheduled regularly in the manner of a standing order or may be prepared individually based on a received order. The quantity of cash received from the vault area 121 will typically be counted, bundled and placed in suitable containers or bags for delivery.

An example of suitable hardware that may be used to implement the present invention is illustrated in Figure 2A. Vault management system 200 comprises a vault management server 210 upon which the vault management software operates. The vault management server 210 is operably connected to database 215. The database may be stored on one or more local or remote storage mediums or devices. Typically, vault management server 210 comprises a standard hardware configuration running Microsoft Windows 2000/2003 or an Oracle-supported host and database 215 comprises an Oracle or SQL Server compatible database. However, any suitable software platform known in the art may be used to implement the invention. The processes used to generate data records and populate the vault management database are discussed subsequently. Sources of data include, but are not limited to, order forecasting systems, high-speed banknote sorters, coin sorters, desktop banknote and coin sorters, document capture systems, CIT providers, remote bank and/or store locations. The vault management database may also be adapted to interface with internal or external accounting or data warehousing systems.

Vault management server 210 typically further comprises a network adapter to connect to a wired or wireless network 231 , using standards such as Ethernet or 802.11g. Network 231 is typically a local area network (LAN) covering the cash

processing centre 105. In Figure 2A network 231 comprises a first network hub 235A connected to a second network hub 235B over a wide area network (WAN) 245. Vault management server 210 may be connected to first network hub 235A via a LAN connection as shown in Figure 2A or alternatively may be located remotely to the cash processing centre 105 and connected to first network hub 235A via a WAN connection. The network 231 is presented as an example and any suitable form of network topology may be used in practice. Network hub 235A is connected to a number of networked devices 220 and 230 and these network connections may also be wired or wireless using known protocols. The network may also be secured using methods known in the art.

Networked devices 220 and 230 comprise networked client workstations 220A and 220B. Such workstations are typically located in the areas of the cash processing centre 105 shown in Figure 1 C: for example workstation 220A may be located in deposit area 111 and client workstation 220B may be located in order area 131. Additional peripherals may also be connected to client workstations 220. In Figure 2A client workstation 220A is connected to barcode reader 225 and client workstation 220B is connected to print device 240. Any number of peripherals may be connected to a client workstation using any known protocols.

A number of banknote counters 230 may also be connected to the network 231, either through client workstations 220A and 220B or through using a banknote counter 230B with network capability, such as counter 230B, connected to the network 231 via network hub 235. These banknote counters may be a 2600, EV86, Evolution (TM), nVision or Kalebra model counter manufactured by De La Rue International Limited or may be any suitable one, two or three or more pocket counter that is adapted to count, validate and/or process batches of banknotes. Networked banknote counter 230B may be located in the any of the cash processing centre areas shown in Figure 1 C.

The example shown in Figure 2A is for illustrative purposes only and the number of client workstations 220 and/or counting devices 230 may vary according to the particular cash deposit centre involved. For example, the deposit area 111

may comprise two or more client workstations 220A wherein each workstation is connected to a barcode reading device 225 and a print device such as print device 240. Alternatively the deposit area 111 may comprise a plurality of banknote counters 230 all connected to network 231.

Vault management system 200 may also comprise a remote client workstation 220C as shown in Figure 2A. This is an optional feature and need not be included in all implementations. This workstation is connected to hub 235B which is connected to the network 231 via a wide area network 245 such as the Internet. Typically, security will be enforced by using a virtual private network (VPN) operating on top of standard communication protocols, such as TCP/IP. Client workstation 220C then allows access to the vault management software running on server 210 from a remote location.

The vault management system of the present invention is implemented using a number of integrated software modules that correspond to each of the processing stages illustrated in Figure 1A. For example, a system based on Figure 1A comprises three modules corresponding to stages 110, 120 and 130. These software modules may be wholly or partly implemented as software processes or interfaces running on vault management server 210. Each client workstation 220 is able to connect to the vault management server 210 and maybe a fat or thin client. Each module typically has its own user interface, typically a graphical user interface (GUI), that is presented to an operator working upon one of the client workstations 220. Each workstation 220 may be restricted to only show the GUI relevant to the area in which the workstation is located, for example workstation 220A may be restricted to only show an operator the GUI associated with the deposit processing module. Each module allows the system to acquire data related to one of the three processing stages, the data being acquired by processes performed by an operator interfacing with the GUI of the relevant module.

As well as a suite of modules corresponding to each of the cash management processes of Figure 1A the vault management software may also optionally comprise a number of additional modules that enable customisable configuration

and provide standing data used by the system. These modules may be one or more of: a security module for managing user access and authorisation levels; a definitions module to manage administration of specific terminology and fixed data; a GUI configuration module to manage the appearance, behaviour and dynamics of each GUI; and a customer database to manage customer specific data reference by the vault management software.

The operations performed in the deposit processing 110 will now be described in relation to Figures 5A and 5B. The deposit processing 110 is performed on one or more quantities of cash that have been received from outside of the cash processing centre. The cash is received in one or more containers that can vary in size and form. These containers may be organised in a nested hierarchy. For example, the cash processing centre may use cages, bulk bags and satchels, wherein a cage may hold one or more bulk bags and a bulk bag may contain one or more satchels. Alternatively, the cash processing centre may use containers, bags and envelopes or a combination of all six container types. Each of the containers may have its own individual identifier, for example in the form of a serial number encoded within a barcode present on the outside of the container.

Each received quantity of cash has an associated deposit slip. This deposit slip lists one or more properties related to the received cash, for example, the originating customer or depositor, the declared deposit amount and the date of deposit. Each container containing a quantity of cash also contains a deposit slip. Containers containing other containers may also contain deposit slips relating to the cumulative deposit amount of all contained containers. The deposit slip may also further comprise a one or two dimensional barcode. This barcode may encode a serial number or actual deposit information. At the deposit stage the quantity of cash within each container is linked to the depositor and verified against the deposit amount declared on the deposit slip.

Figure 5A shows a method for obtaining the deposit data associated with a deposit. At step 505 an operator logs into the deposit module using a client workstation, such as workstation 220A. The login procedure may involve

entering a user name and password. In some embodiments the workstation 220A may be connected to a biometric device adapted to read a biometric identifier associated with the operator. This identifier may be a finger print, a finger or palm vein structure, an iris scan or a voice print (amongst others). Hitachi Ltd provides a number of reading devices which may be used to read the biometric identifier. The biometric identifier is then used instead of a username and/or password to log in to the relevant software module.

The operator then selects a deposit container for deposit processing 510, opens the container and retrieves the deposit slip. A new deposit record is then created if no pre-existing record exists. The information present on the deposit slip is then obtained 515 using one or more of automatic means, for example scanning a barcode 515A present on a deposit slip or applying optical character recognition (OCR) to a captured image of the deposit software, or using manual means, for example entering the information 515B, 515C into the deposit module GUI. As a deposit operator will regularly spend a large proportion of their time entering deposit information all functions within the deposit module are accessible with keystrokes or by assigning hot keys. If a barcode is present then the operator can use a barcode scanner 225 to either retrieve a serial number or the deposit data itself. A serial number may be linked to a deposit record generated by the depositing customer or may identify the depositor. Other data that maybe recorded include a till, cashier, store or branch identifier. Once the depositor information has been entered then the deposit record is updated 520. If it is not assigned already the cash deposit is assigned to the current operator by associating an operator identifier, such as a user name, with the deposit record. This may be achieved by associating the user name of the current active operator with the deposit record. A cash deposit may also be assigned to an area, for example deposit area 111, as well as, or instead of an operator. This makes the current operator and/or area responsible for the cash deposit until a transfer is performed.

The data present on the deposit slip may also be obtained using pre- advisement. Pre-advisement involves the customer pre-advising the cash processing centre on the nature of a deposit. Typically, this may be performed

using a web interface wherein the customer enters the deposit amount and container identifiers while preparing the deposit. This deposit data is then linked to the cash processing centre receiving the deposit. When a container is subsequent sent and received by the cash processing centre the pre-entered deposit information can be retrieved upon container identification, e.g. when the containers making up the deposit are scanned by an operator.

After initial deposit processing a count and verification process begins. The count and verification process is illustrated in Figure 5B and is performed by an operator interacting with an adapted GUI of the deposit module. The method 501 begins at step 520 with the retrieval of cash, typically in the form of banknotes, from the selected deposit container. The cash is then counted at stage 535. Counting may be performed manually or, as is typically the case, may be performed by an on-line or off-line banknote counter 230. If the cash processing centre is configured to receive and process cheques then cheque imaging systems and software may also be integrated into the vault management system to provide count information for cheque deposits.

In a manual count the operator counts and inspects the cash from the container and enters the results of the count into the deposit module GUI. Typically, the cash is sorted into a number of denominations and the total number of notes and cash value of each denomination is recorded. The fitness of each note can also be inspected and the serial numbers recorded. If a banknote counter 230A is currently connected to the client workstation 220 at which the current operator is operating, i.e. is on-line, this will be shown within the deposit module GUI and the banknote counter can be used to generate data documenting characteristics of counted notes. These can be, amongst others, denomination, fitness, and authentication characteristics. To use an on-line banknote counter the operator places the retrieved banknotes on banknote counter 230A. The banknote counter 230A is then able to count and/or verify the banknotes and the data generated by the banknote counter 230A is sent back to the client workstation 220A to populate the count data at stage 540. Alternatively banknote counter 230A can be disconnected from the client workstation 220A, i.e. used off-line. In

this case the banknotes will still be counted by the banknote counter but the operator will manually enter the data on the banknote counter display. If the banknote counter 230A is adapted to authenticate the banknotes and identify counterfeit notes then data related to counterfeit notes may either be passed automatically to the deposit module from the banknote counter if the counter is on-line or may otherwise be manually entered into the adapted deposit GUI based on data presented to the user on the banknote counter display. Data on counterfeit notes can then be printed by a user or supervisor to comply with legal reporting requirements. If an error occurs when using a banknote counter an operator is also able to edit any captured data manually by interfacing with the deposit module GUI.

After the banknotes have been processed at step 535 and the count data has been populated at step 540 the populated count data is compared with the deposit amount entered into the deposit module from the deposit slip. This is performed at step 545. At this stage, to provide extra security, the result of the comparison may be reviewed by a supervisor at step 550. If this is the case a supervisor is summoned and logs into the vault management system. Once the supervisor is logged in they are presented with a screen summarising all information relevant to the current deposit. They are then able to review any difference found between the counted amount and the amount on the deposit slip. If a difference is found at step 555 then this is displayed to the supervisor and the supervisor is asked to enter a reason for the difference at step 560. If no difference is found then the supervisor may be asked simply to confirm the count data. Whatever the result, the supervisor then captures an image of the deposit slip at step 565. This may also be performed by the operator. This typically involves placing the deposit slip underneath a digital camera connected to client workstation 220A. The digital camera is adapted to take a picture of the deposit slip and store it with the deposit record in deposit database 215. After the count has been performed the operator in the deposit processing area 111 the cash is transferred to the vault area 121. Typically, after processing, the cash is retained in a secure container whose ownership is attributed to the operator, machine or area responsible for deposit processing.

The transfer of cash from the deposit area 111 to the vault area 121 involves a transfer process as illustrated in Figures 3A and 3B. The transfer process is used to transfer responsibility for the cash deposits from deposit processing 110 to vault processing 120. The transfer process performed by the party wishing to transfer a cash deposit, in this case an operator DP within deposit area 111, is shown in Figure 3A. The operator begins by initiating a transfer module upon client workstation 220A as shown in step 305. The operator then selects the source of the transfer in step 310. The source may be an individual, an area or a safe, a safe being a subdivision of the vault. The selection may be achieved by either selecting the relevant user name or area from a dropdown list, retrieving the current logged in user name or area from the client workstation operating parameters. Once the source of the transfer has been selected the containers and/or cash deposits currently assigned to the source may be displayed to the user via in an information panel within the GUI.

At step 315 the operator selects a destination, which may also be an individual, an area or a safe, a safe being a subdivision of the vault. For example, the destination may be a user V in the vault area 121. This selection may again be made through the use of a dropdown menu. Once a user and/or area have been selected as a suitable destination the containers and/or cash deposits belonging to the selected destination may be displayed in an information panel.

Once the source of the transfer and the destination of the transfer have been selected in steps 310 and 315, the number of items to transfer is then entered in to the transfer module GUI at step 320. These items can be containers or discrete bundled quantities of banknotes representing a cash deposit. As discussed previously each container has an identifier and this identifier can be in the form of a barcode. Each bundled quantity of cash may also have an identifier in the form of a barcode. Once the number of items to transfer has been entered at step 320, the identifiers corresponding to the items that are to be transferred are entered into the transfer module GUI. For example, if barcodes are used these can be scanned at step 325 to obtain serial numbers identifying each item. As each item is identified it may be passed across the physical boundary 141 separating the deposit area 111 from the vault area 121.

Each identified item is counted and the total number of identified items is compared with the quantity entered in step 320. Once all the items for transfer have been identified then the transfer is confirmed at step 330.

In order to complete the transfer process a transfer must be acknowledged by or at the destination. In the present example, this could be operator V in the vault area 121. An acknowledgement can be performed in one of three ways:

• The system can be set up to automatically acknowledge any transfers as soon as they have been confirmed by the operator at step 330. • The receiving party can follow the steps shown in Figure 3B. At step

350 the destination operator logs into the vault management system via a client workstation 220 and initiates an acknowledgement module 350. In certain configurations the acknowledgement module automatically identifies the current user and/or destination area based on the operating parameters of the current client workstation and in other configurations the acknowledgement displays a series of users, areas or safes for the operator to select. Once one of a user, area or safe has been selected the current number of transfers awaiting acknowledgement are displayed. The operator then selects one of these transfers at step 355 and interacts with the GUI of the acknowledgement module to acknowledge the transfer.

• In addition to the steps of Figure 3B described above the receiving party may also re-identify the items at step 365 in order to acknowledge the receipt. For example, the barcodes of two bulk bags received from the deposit area 111 may only be acknowledged when their barcodes are scanned using a barcode scanner 225 connected to a client operating system 220 present in vault area 121. This option is the most secure and means that items can only be acknowledged once they are physically received.

This transfer process described above manages the physical responsibility or "ownership" of containers and/or cash deposits. This allows all physical movements of containers and/or cash deposits between operators and/or areas of the cash processing centre to be recorded by the vault management system

as database records. The vault management system running on vault management server 210 stores records of each transfer and each acknowledgement in database 215. Thus these records can be queried at any time in order to investigate a transfer process. For example, if a transfer has been initiated by one party but the transfer has not been received by a second party then the transfer records for the initiated transfer can be examined and details such as the container identifiers, cash amount, date, time, user and/or area can be retrieved to aid investigation.

Once the cash is in the vault area 121 it will often be processed and stored. This may involve removing the cash and re-bundling sets of banknotes in set bundles of a particular denomination and a particular fitness. For example, banknotes may be sorted into those that are fit for automatic teller machines (ATMs) or those that comply with the Banknote Recycling Framework (BRF).

The vault management system further comprises a vault module that allows the physical inventory of the vault or secure area of the cash processing centre to be accurately represented in real time. As all cash deposits are transferred to the vault the vault module is able to calculate the exact quantity of cash within the vault by using the count and denomination records, linked to the transferred item, that were generated during deposit processing 110. To facilitate management of the vault inventory the vault module further has the ability to generate virtual areas or safes within the vault area 121. Items such as containers or bundled quantities of cash can then be assigned to specific virtual areas through the transfer process of Figures 3A and 3B. For example, virtual areas could be generated to hold reserve notes, new notes, coins, ATM fit notes, notes for a particular customer, notes for destruction, old issues of notes, containers, bags, cages, or to represent designated areas such as processing areas or order preparation areas. This can enable management to view all available cash of a given type at a given time, for example all ATM fit cash and then manage the cash flow process accordingly. These virtual areas may have a physical counterpart but this need not be the case, so quantities of cash present in a set physical area of the vault may belong to different virtual areas or safes.

Vault processing 120 may also involve reclassification of cash media. For example, 100 x $1 coins may be reclassified as a 1x$100 rolled coin package. This can help to simplify and refine later order processing. Alternatively, if fitness and authentication sorts are not performed as part of the deposit processing 110 then the resultant quantities of cash will be set as "unclassified". Within vault processing 120 these quantities of cash can be further sorted for fitness and authentication and the results of the sort process can be used to perform the media reclassification. This can enable the true state of the cash or media within the vault to be ascertained. Additionally, by altering the stage at which media classification is performed the processing workload can be actively split between deposit and vault processing.

Cash remains in the vault area 121 until it is required to fulfil a cash order. Figure 6 illustrates the steps involved in order processing 130. A cash order comprises a request for a set quantity of cash from a customer. This request may be for a variety of articles of value, such as coins, notes or bonds and may also include an order for associated servicing, such as ATM servicing. At step 605 the details of the cash order are received or generated. Cash orders may be one off orders or may be part of a regular standing order. Cash orders are stored as records in an order database which may be implemented as part of vault management database 215. Orders may be received via a variety of communication means, for example facsimile, telephone, email etc, and may be manually or automatically entered into the order database. Orders may also be automatically generated based on forecasting systems that interface with the cash management system.

Once a cash order is received an order processing module verifies the customer making the request and checks that the customer is on, or can be assigned to, a valid delivery route. The delivery date of the order is also checked to confirm that it is possible make the delivery and if the delivery date is not possible an error is returned. The order amount is checked against the inventory of the vault 121 to confirm that there is enough stock to complete the order. Orders are then queued and grouped by delivery date.

Before an order can be prepared it needs to be activated and allocated to an operator within the cash processing centre. This is typically performed by a supervisor using a client workstation such as client workstation 220B within the order processing area 131. The supervisor logs into an order preparation module, which forms part of the order processing module, and is presented with a list of orders available for preparation. Commonly, the list is filtered to show a subset of orders, for example those needing to be prepared for the current day, and the supervisor can view the details of each order by selecting one of the list. To activate an order at step 610 the supervisor selects the order from the list and confirms that it is to be activated. At this stage orders can be assigned one of a plurality of types which will dictate any special preparation requirements. Once an order is activated its status is changed to awaiting preparation. This status change is a one way process and activated orders cannot be modified or deleted.

Once an order has been activated operators within the vault area 121 prepare the cash required to make up the order. At this stage the system may also perform an inventory check. This may involve counting out the amount of cash stipulated in the order. After the cash has been prepared it awaits collection by an operator from the order processing area 131.

Meanwhile, after activation of the order, the supervisor proceeds to allocate the cash order to a user and/or an area. Typically, this is an operator within order processing area 131. To allocate an order at step 620 the supervisor selects an activated order and then selects the required user and/or area in a similar manner to the selection of a destination in the transfer process. It is also possible to allocate more than one cash order. Once an order has been allocated then a pick list or manifest can be printed at step 625. The pick list contains details of the cash order and may have a barcode encoding a unique serial number associated with the order. Typically, the pick list is printed by the printing device 240 connected to the client workstation 220B within the order processing area 131. The pick list may comprise a number of individual manifests corresponding to each required container.

Once the responsible operator receives the pick list they are able to retrieve the cash required to make up the order from the vault. This requires a transfer process 630 as shown in Figures 3A and 3B. The printing of a print list at stage 625 may automatically generate a transfer process to transfer banknotes from the vault area 121 to the order processing area 131. Alternatively the transfer process can be performed by an operator in the vault area 121 at the request of the order processing operator. In any case, the stages in Figure 3A are performed with regard to a number of prepared bundles of banknotes. The operator within the order processing area 131 then receives the banknotes and the transfer process can be acknowledged by the order processing operator as shown in Figure 3B.

At step 635 a number of containers required to hold the cash order are prepared. The number and type of containers required may be calculated automatically when the order is activated and may be present on the pick list.

For example, orders can be supplied in cassettes, bulk bags or satchels. The containers are retrieved from a stock of fresh or un-used containers and these may be present in the order processing area 131 or maybe retrieved from the vault area 121. As with received deposits, each container is typically assigned a unique identifier. This may be encoded as a barcode. The barcode may already be present on the container or the client workstation 220B within the order processing area 131 may generate and print new barcodes using a connected label printer. Hence, before picking an order the allocated operator is provided with a pick list, a number of identified containers and a quantity of cash from the vault.

An activated order can only be prepared by an allocated operator. Hence the picking process begins when the allocated operator logs into a client workstation, such as workstation 220B, in order processing area 131. The allocated operator is then presented with an order preparation screen. This displays all pending orders that have been allocated to the current operator in an information panel. To perform the picking process at step 640 the allocated operator first selects a pick list and enters the pick list identifier. This may involve

scanning the barcode present on the pick list. The entering of the identifier brings up the details of the order on the operator's screen. These details include the number of containers required and the amount of cash or number of banknotes to be placed in each container. The operator begins with a first order container and enters the container identifier associated with the first order container. This may involve scanning a barcode related to that container. The operator is then informed of the quantity of cash to be placed within the container. If the cash is in the form of bundled banknotes a number of bundles can be taken and placed into the container to pick the order. If the cash is provided in the form of a heterogeneous group of banknotes or other documents then the cash may be counted by an attached banknote counter, such as counter 230C. If said counter is connected to the client workstation then the order processing module may automatically pass the required count amount to the counter. The operator then need only place a quantity of banknotes upon the counter and the required amount will be counted into an appropriate output hopper. The operator can then simply remove the banknotes from the output hopper and place them in the associated container. If each container has its own manifest or the order is complete, the appropriate pick list is placed within the container and the container is then sealed. The pick process is then repeated for any additional containers that make up the order.

After the picking process a balance is calculated for the user based on a comparison of the quantity of cash received from the vault with the quantity of cash placed within the one or more containers. These quantities should be equal and if they are not then a supervisor can be called over to log in and confirm the reason for this difference. If an error occurs during the picking process then picked quantities of cash can be retrieved from assigned containers but the associated container identity is destroyed and a new container identity is generated. The end result of the order processing process 130 is one or more containers filled with a quantity of cash that fulfils a given customer order.

Figure 1B illustrates an extended cash management process 101 according to a second embodiment of the present invention. This process 101 provides an

extension to the cash management process 100 shown in Figure 1A. The extended cash management process 101 further comprises the processes of cash reception 150 and cash despatch 160. The incoming delivery of cash deposits and the outgoing despatch of cash orders may be performed by the same organisation that runs the cash processing centre or may be performed by a third party. Although the present example is described with the inclusion of the reception 150 and despatch 160 stages it should be noted that these stages are optimal and the present invention can be implemented using any of the stages shown in Figure 1A.

Figure 10 illustrates an example schematic of an extended cash processing centre 106 according to the second embodiment of the present invention. Extended cash processing centre 106 comprises deposit processing area 111, vault area 121, and order processing area 131, as present in the standard cash processing centre 105 of Figure 1C, but also further comprises reception area 151 and despatch area 161. Reception area 151 may be separated from the deposit area 111 by physical boundary 171 as shown in Figure 1 D. If so, access to the deposit area 111 from the reception area 151 is provided by entry point 156, through which cash can be transferred as shown by arrow 157. Alternatively, the reception and deposit areas may be provided by a single area. Despatch area 161 may also be separated from order processing area 131 by physical boundary 171. If so, access to the despatch area 161 from the order processing area 131 is provided by exit point 136, through which cash can be transferred as shown by arrow 137.

Figure 1E shows an alternate layout for a cash processing centre, wherein features equivalent to those shown in Figures 1C and 1D are given identical reference numerals. Delivery bays 151 and 161 are used as reception and despatch areas, wherein delivery vehicles may reverse into said bays to load and unload cash deliveries. Deposit area 111 comprises two areas: area 111 A comprising desk-top machines similar to workstation 220A and area 111B comprising large banknote sorters and a reject entry station. Selected deposits and rejected notes will pass from area 111A to area 111B through entry way 181. Vault 121 is located in the centre of the cash processing facility and

receives cash from area 111 A via route 117 and area 111 B via route 182. Order processing area 131 receives cash from the vault 121 and picks orders to supply to the despatch area 161.

Cash reception 150 involves the receipt of containers that contain cash for deposit. Commonly, these containers are received from CIT operators which transport cash deposits from parties who are located at a distance from the cash processing centre. For example, at the end of a trading period, a bank may commission a CIT operator to pick-up cash from the bank's branch and transport it to the cash processing centre. During cash reception 150 the cash processing centre is responsible for unloading containers containing cash deposits from a CIT vehicle and documenting the newly acquired ownership of these containers. Responsibility for these containers can then be transferred to deposit processing 110. In a similar manner to the boundary line 140 in Figure 1A, the extended cash management process 101 of Figure 1B contains figurative boundary line 170. This separates the process of cash reception 150 from the process of deposit processing 110 and reflects the organisation of the discrete components of the vault management system.

An example of the cash reception process 150 is shown in Figure 4. The method 400 shown in Figure 4 is implemented when a cash deposit is received at the reception area 151. For example, the method may be initiated when a CIT vehicle arrives. As with deposit and order processing, the cash reception process is performed by an operator resident in reception area 151. The operator has access to an additional client workstation within the reception area 151. On arrival of a cash deposit, if an operator is not already logged in, the operator loads a cash reception module and logs into the system using their user name and password.

The operator then proceeds to capture data associated with the cash deposit. This begins with the step of entering the carrier or the route details 405 into the vault management system. Typically, this involves entering a carrier or route identifier from CIT or deposit documentation. This identifier can either be

entered manually by the operator or automatically by scanning a barcode encoding the identifier.

At the next stage 410 deposit information related to the received cash is entered into the vault management system. This may comprise the number of containers being deposited or may comprise additional details such as the name of the depositing customer and/or the deposit amount. In a similar manner to the entry of the carrier or route details 405 the deposit information may be entered manually by the operator or may be retrieved from data encoded into the CIT or deposit documentation. At the next stage of the method the identifiers of the received containers containing the cash deposit are entered into the system.

Typically, each container has an external barcode encoding the container identifier and this is scanned using a handheld barcode scanner in step 415.

The cash reception module then stores the identifiers of each container and verifies that the number of containers present in the CIT or deposit documentation matches the number of identified containers.

Once all the received containers have been identified to the system then reception of the deposit is confirmed at step 420. This can be achieved by pressing an icon within a GUI used to implement the cash reception module. On receipt of a new cash deposit a number of new deposit records are created in the vault management database 215. Each container will have its own associated record which will contain information about its source, its contents and other processing information. When the reception of the cash deposit is confirmed at the confirmation stage 420 these records are permanently stored in the vault management software database 215 and the containers are assigned or allocated to the current operator and/or area. At this stage, "parent" containers containing one or more other containers may be unloaded or loaded to facilitate deposit processing. Before transfer to the deposit processing area 111 a reception operator is also able to re-load the reception module and edit any incorrect data.

Once a number of containers containing cash deposits have been received and documented in reception area 151 the containers are transferred to deposit

processing area 111. Physically this is normally achieved using entry point 156. As well as physically transferring containers of cash between area 151 and 111 the reception operator must also complete a transfer process. As before, this transfer process is required to record the movement of the cash deposit containers. Hence the reception operator performs the steps of Figure 3A whilst an operator in the deposit processing area 111 acknowledges the transfer, for example using the steps of Figure 3B. Deposit processing can then begin as described with relation to Figures 5A and 5B.

The extended cash management process 101 of Figure 1B also includes a despatch stage 160. After an order of cash has been processed by the order processing stage 130 it is typically sent to the despatch stage 160 to be despatched to the customer requiring the cash. The delivery is normally performed by a CIT operator. The despatch stage also records the transfer of responsibility from the cash processing centre to the party responsible for the delivery. The steps performed during cash despatch are shown in Figure 7.

The result of the order processing stage 130 is a number of containers containing a quantity of cash to fulfil a cash order. Once an order has been prepared and processed it is transferred to the despatch area 161 to await despatch. Physically, this is often performed using a secure exit point 136. As part of the management process the one or more containers that contain the cash required for the cash order are also transferred to the despatch area 161 using a transfer process 135 as described previously with relation to Figures 3A and 3B. The transfer process is initiated by an operator within the order processing area 131 and a second operator logged into a client workstation within despatch area 161 acknowledges the transfer as well as physically receiving the containers.

Once in the despatch area 161 the operator may combine a number of cash orders into a shipment, as is shown in step 705 of Figure 7. A shipment corresponds to a plurality of customer orders that will use a common despatch route or CIT operator. Alternatively, orders may be grouped into a shipment by management personnel or automatically based on scheduling considerations. In

any case, when the despatch operator logs into the vault management system and loads a shipment module they are presented with a screen displaying all shipments scheduled for the present day. The shipment module may also display whether all containers for a given shipment are available for despatch or whether a shipment is incomplete or over-subscribed. Containers for a given shipment may be prepared in step 710 by physically grouping the shipment containers in a reserved section of the despatch area 161. Each shipment may have an associated printed manifest documenting the details of the shipment.

When the appropriate transport vehicle arrives at the cash processing centre the despatch operator begins the despatch process. The operator begins by loading the despatch module on a client workstation and selecting the route used by the waiting transport vehicle. The despatch operator then enters or selects the relevant shipments for that route and enters the number of containers to load onto the vehicle for each shipment at step 720. This may be achieved by scanning the barcode of a shipment manifest to retrieve a shipment identifier. The identifiers of all the containers to be despatched are entered into the despatch module which assigns these containers to the operator of the transport vehicle. This may be achieved by scanning container barcodes that encode a unique container serial number, as is set out in step 725. The identification of the containers making up the shipment transfers ownership of the containers from the despatch area 161 to transport vehicle operator. The order containers are then physically loaded onto the transport vehicle in step 730. A manifest related to the shipment and documenting the transferred containers may be generated in step 735. This manifest may be printed onto paper or may be stored electronically. The transport vehicle is then ready to depart the cash processing centre with the loaded containers.

A third embodiment of the present invention is shown in Figure 8. This embodiment combines the vault management system of the first or second embodiment with a close circuit television (CCTV) system; the embodiment comprises the hardware components of Figure 2A but then further comprises CCTV cameras 820 and a CCTV multiplexer and recorder 810. Typically cameras 820 are digital CCTV cameras and CCTV multiplexer and recorder 810

is adapted to store digitally recorded CCTV footage in database 815. Digital CCTV systems capture a video using high-capacity, high-speed multi-channel digital recorders. Such systems typically hold a vast amount of video footage and allow quick access to video files stored in database 815.

Using the assignment of containers and assets, together with the transfer process, the vault management system of the first and second embodiments is able to capture data related to all cash processing actions in its database. Each recorded action, for example a transfer, count or reception operation, will have an associated date, time and location. In a similar manner the CCTV system will monitor set locations and will index each video recording using a date and a time. Hence, as both the vault management system and the CCTV system are commonly linked by location, date and time parameters it is possible to retrieve video footage from database 815 based on a location, date and time specified by the vault management server 210.

For example, a supervisor may wish to view the transfer of a set of containers between the order processing area 131 and the despatch area 161. Such a transfer will have an associated transfer record in the vault management database 215. This transfer record will then comprise data specifying an associated set of locations (areas 131 , 136 and 161) and an associated date and time. The vault management server 210 is then adapted to supply these parameters to the CCTV multiplex and recorder 810 which is able to retrieve the appropriate video from video database 815. The supervisor is then able to view the video footage for that location, date and time.

As well as integrating the vault management data with a CCTV system other supervisor functions may also be optionally integrated to facilitate management of the cash processing centre. The supervisor functions described herein may be used with any embodiment of the present invention. The interfaces for these supervisor functions can be viewed using a remote client workstation such as workstation 220C. The first of these modules is an investigation and research module. This provides a front-end to the vault management database enabling the supervisor to query and view all deposit transactions, all transfer processes

and all inventories across any networked cash processing centres, including user and/or area inventories. Each query or inventory may also be printed as an electronic or paper report. Reports include, amongst others, operator productivity, discrepancy pattern analysis, deposit quality per depositor, counterfeit frequency per depositor or ATM fit note yield per depositor. Discrepancies reported by customers can be investigated by recalling all data associated with the deposit and/or cash order in question, including the image of the deposit slip. Discrepancy reports can then be generated and printed or sent electronically. In some configurations it is also possible to provide keystroke and/or device logging that can provide an extra level of information for audits or investigations.

A supervisor may also be provided with a stock balancing function that can be used to balance stock at the end of a working day or shift. The exact time or event that triggers a balance procedure is configurable. An operator first uses the system and logs into the balance module. They then select their name from a list onscreen and are presented with a list of the stock that is currently assigned to them. The operator then performs a count of the cash within their work area and enters the count result into the module. This process may also be performed without displaying the expected stock to perform the balancing "blind". If a difference is found between the expected and actual stock count the module will prompt the operator to perform a recount. If after the recount an imbalance still remains a supervisor is summoned. The supervisor is then able to adjust the balance if need be or investigate any discrepancy.

The ownership, count, sort, inventory, reclassification and order processing data can be used together with other relevant collected data to provide a real time summary of key performance indicators. These may be displayed visually to a supervisor or an operator. Any known data processing used in the art may be applied to the data to provide appropriate management information to a wide variety of personnel, from senior management to low-level operators.

A fourth embodiment of the present invention is illustrated in Figures 2B, and 9 to 11. This embodiment provides an alternative method for performing deposit processing 110 that is adapted to handle large quantities of cash.

Figure 2B illustrates a suite of exemplary hardware components that may be used to implement the fourth embodiment of the present invention. Such hardware as described below may also be used to implement any of the other embodiments of the present invention described herein. Figure 2B shows two networks 231 A and 231 B that communicate with each other and a remote client workstation 220C using WAN 245. Each network 231 A and 231 B is connected to a respective router 235C and 235D which then provides the gateway to the WAN. Remote client workstation 220C is connected to a third router 235E via firewall 250. Each network 231 A and 231 B may correspond to two different areas of a cash processing centre, for example deposit area 111 and order processing area 131 , or to two physically separate cash processing centres belonging to a single organisation.

Top network 231 A is connected to vault management server 210 and mirror or FtAID (Redundant Array of Independent Disks) server 211 which together run the server operations of the vault management software and include a vault management database (not shown). Lower network 231 B interfaces with vault management server 210 via the WAN 245. Both networks further comprise uninterruptible power supplies (UPS) 255A and 255B, reports printers 240, client workstations 220A and connected handheld barcode scanners 225 and currency sorting machines 260D and 260E. An exemplary currency sorting machine 260 is illustrated in Figure 11. The machine 260 comprises document feed area 1012 and document output hoppers 1014. The document output hoppers further comprise reject hopper 1014R. While the fourth embodiment is described with regard to the hardware configuration of Figure 2B it is not limited to such a configuration and can be used with any other suitable configuration including that of Figure 2A. In the latter case banknote counter 230A is replaced by currency sorting machine 260.

Multiple cash processing centres may record data such as ownership transfers, count data and inventory information on a single central database server. This central database server may comprise a primary and back-up server and be accessible from each cash processing centre over a WAN. The database server may also be accessible from a central administrative head-quarters or office. The database server may also provide some or all of the functionality of vault management server 210 and may be connected to a network resembling network 231 A but without the cash processing centre workstations 220 and banknote counters 260. Standard firewall technology can be implemented so that networked machines within a cash processing centre can only see data upon the database server that relates to the centre in question. However, administrative machines may be able to access, view and aggregate data from a plurality of cash processing sites.

The method of the fourth embodiment illustrated in Figure 9 provides an alternate method for performing deposit processing as illustrated in Figures 5A and 5B. In the first and second embodiments each deposit is commenced, counted, validated and completed prior to moving onto the next deposit. The cash pertaining to such a deposit typically remains with a deposit operator at all times. In the fourth embodiment a plurality of deposits are batched together and processed in a continuous cycle away from the desk of an operator.

The method of deposit processing according to the fourth embodiment involves three main stages: preparation; note sorting and deposit counting; and reject entry. Reject entry comprises capturing data related to notes that were rejected within the sort process. Such notes may be damaged or counterfeit.

The method 900 of Figure 9 commences after an operator within the deposit processing area 111 receives one or more containers containing a cash deposit. The operator performs the steps of Figure 5A as per the first embodiment but at step 520, when the deposit record is updated, the deposit is assigned a unique deposit identifier as shown in step 905. This deposit identifier allows the deposit to be tracked for the duration of the deposit processing. For large deposits the deposit may be split into a plurality of smaller deposits which will each be

assigned a unique deposit identifier. Once the deposit identifier has been assigned a set of two separator documents are generated at step 910. The deposit is then arranged in a deposit batch in step 915.

A series of three deposits and their associated separator documents 1112 that make up an exemplary deposit batch are shown in Figure 11. The separator documents are designed to be placed around a bundle of banknotes 1116, 1120, 1124 making up the deposit and comprise a "first" or downstream document, 1119, 1121 and 1123, and a "second" or upstream document, 1118, 1122 and 1126, wherein the banknotes are configured to be fed in the direction of arrow 1127. The first separator documents 1119, 1121 and 1123 act as a trailer and the second separator documents 1118, 1122 and 1126, act as a header. Each header document comprises one or more magnetic strips on the rear (downstream) side of the document and a barcode on the front (upstream) side of the document. The unique deposit identifier is typically encoded in both the barcode and the magnetic strip.

Alternatively, the separator documents may be taken from a stock of pre-existing separator documents. In this case, each the barcode and magnetic strip(s) encode an arbitrary serial number. This serial number is then assigned to a deposit at step 905 by scanning the barcode on each header document whilst putting together the deposit batches.

Each deposit batch is commonly arranged on a deposit tray that is adapted to feed a currency sorting machine 260. A deposit batch may contain a plurality of deposits from difference customers. Once a deposit tray is full, or a deposit batch reaches a predefined size, it is taken by an operator to the currency sorting machine 260 for processing and counting at step 920. The deposit batches, complete with separator documents, are placed onto a feed mechanism of the currency sorting machine 260 at feed area 1012 and the machine continuously feeds the note into a note processing area. The processing performed by the currency sorting machine 260 incorporates one or more of counting, authentication, fitness and denominational sorting in a single process run and typically provides all four forms of processing. During the sort

process detectors within the machine inspect both the banknotes and separator documents. When the machine encounters a header document it reads the unique identifier on the document encoded in either the magnetic strips or the barcode. This identifier is then associated with the sort or process records of the subsequent banknotes. When the trailer separation document is then subsequently detected the machine then disassociates the unique identifier from the sort or process records of subsequent banknotes.

Sorted banknotes are provided to output hoppers 1014 depending on the sort process. For example, a detector may be provided for determining the denomination of each banknote and another detector for determining authenticity. If a banknote is found to be authentic and its denomination can be determined, it will be directed to a particular output hopper for stacking genuine banknotes with that denomination. All other documents either non-genuine or unreadable banknotes or separators are fed to the reject hopper 1014R.

The processing data associated with a deposit amount originally situated between the separator documents is sent by the currency sorting machine 260 via network 231 A to vault management server 210. The server then populates the deposit count and processing data at step 925 using the unique deposit identifier as an index.

Reject banknotes fed to the reject hopper 1014R remain sandwiched between their associated separator documents and form reject deposit batches. These reject deposit batches are then taken to a reject processing station wherein the reject notes are processed a second time at stage 930 to ascertain the reason for rejection and/or possible detect good notes that were not detected on the first pass (for example if they were rejected as overlapping or misted notes). The reject data is also associated with the unique identifier on the header document and is sent to the vault management server to update the deposit count and processing data. Alternatively, the reject notes can be manually inspected by an operator. In this case the operator will manually scan the barcode on the associated header document and enter the reject data.

Once process data for all the banknotes within the deposit has been ascertained then this data is automatically reconciled with data obtained from the deposit slip at step 935. As with the first embodiment any discrepancies are flagged to a supervisor in a management report produced at step 940.

The benefits of the fourth embodiment are numerous. The deposit processing is performed in one continuous process and a high level of accuracy, integrity and security is maintained. Added security can be provided by performing the processing "blind", i.e. the operator responsible for operating the counter and/or entering reject information is unaware of the depositor details.