AU2006200687B9 - System and method for monitoring a validator - Google Patents

Abstract

-32 A system for monitoring a validator that assesses a token is disclosed. The system includes an input device 4 for receiving messages 5 from a machine 2 including a validator 6. The messages containing data indicative of validator events such as an assessment of a token resulting in 5 acceptance of the token and an assessment of a token resulting in rejection of the token. The system further includes a processor 7 for deriving timing information for the validator events and for comparing the data and timing information with predetermined criteria. Personnel alerts are raised when predetermined criteria are satisfied, and maintenance of validators may be scheduled in dependence upon criteria related to assessments of tokens resulting in rejection. 10 [Figure 2) (Z

Description

- 1 AUSTRALIA PATENTS ACT 1990 COMPLETE SPECIFICATION FOR A STANDARD PATENT ORIGINAL Name of Applicant: eBet Limited Actual Inventors: Tony Toohey and David Jack Address for Service is: SHELSTON IP 60 Margaret Street Telephone No: (02) 9777 1111 SYDNEY NSW 2000 Facsimile No. (02) 9241 4666 CCN: 3710000352 Attorney Code: SW Invention Title: SYSTEM AND METHOD FOR MONITORING A VALIDATOR Details of Associated Provisional Application No. 2005900774 dated 18 Feb 2005 The following statement is a full description of this invention, including the best method of performing it known to us: File: 44774AUP00 5Qa9O472_1.00OC5M44 -2 FIELD OF THE INVENTION The present invention relates to a system for monitoring a validator for assessing a token and methods for monitoring a network of machines including such a validator. The invention has been developed primarily for use with electronic gaming machines 5 (EGMs) and it will be described hereinafter primarily with reference to this application. However, it will be appreciated that the invention is not limited to this particular field of use. In particular, the invention also finds application in the fields of vending machines and systems for controlling access to a location, a resource or an account. BACKGROUND 10 Any discussion of the prior art throughout the specification should in no way be considered as an admission that such prior art is widely known or forms part of common general knowledge in the field. EGMs which allow a user to play a game upon purchase of credit are known. Such EOMs generally include a validator for assessing token of some description, which is presented or 15 inserted by a user to effect payment for credit. The token may be a banknote or a coin inserted into the machine, for example. In such cases, the inserted currency must be assessed to ensure that it is not counterfeit or foreign currency. In other cases, the token may be a card having a magnetic strip or a chip, or it may be a radio frequency (RFJD) tag identifying a particular user or a user account. In such cases, the token must be assessed to ensure that it is of a type that 20 may be used to purchase credit. Various devices exist to perform this assessment: coin acceptors assess coins; bill validators assess banknotes; and card and tag readers read cards and RFID tags. Except where a more limited construction is clearly intended, the term "validator" in this document includes any device for assessing a token used to obtain credit for, or access to functionality of, a machine, or 25 access to a location, a resource, or an account. It is known for validators to store status information indicative of, for example, the number of assessments performed and the number of tokens accepted/rejected. This information is accessible by maintenance or other personnel for determining whether maintenance of the validator is necessary 3 Summary of the Invention [0007] It is an object of the present invention to overcome or ameliorate at least one of the disadvantages of the prior art, or to provide a useful alternative. [0008] According to a first aspect of the invention there is provided a system for monitoring a validator that assesses a token, the system including: an input device for receiving messages from a machine including a validator, the messages containing data indicative of validator events; and a processor for deriving timing information for the validator events from the messages and for comparing the data and timing information with predetermined criteria; wherein the input device is adapted to receive messages indicative of the following validator events: an assessment of a token resulting in acceptance; and an assessment of a token resulting in rejection; and wherein the processor is adapted to determine walk-away events by comparing the timing information with the predetermined criteria, wherein walk-away events are occasions when an assessment of a token resulting in rejection is followed by a period of greater than a predetermined threshold duration without an assessment resulting in rejection or an assessment resulting in acceptance, and wherein the processor is adapted to electronically store records of the determined walk-away events, acceptances, and rejections and to electronically generate an alert in response to determination of a selected criterion based on at least one walk-away event. [0009] Preferably, the processor derives the timing information by extracting timestamp information from the messages. [0010] Preferably, the processor derives the timing information with reference to the time of receipt of the messages by the input device. [0011] In the preferred embodiment, the input device is adapted to receive messages indicative of the following validator events: an assessment of a token resulting in acceptance; and an assessment of a token resulting in rejection. However, the input device may also be adapted to receive messages indicative of the following additional validator events: removal of a token storage device for storing accepted tokens; and acceptance and storage of a token resulting in a token storage device being full.

4 [0012] Preferably, the processor is adapted to determine occasions when an assessment of a token resulting in rejection is followed by a period of greater than a predetermine duration without an assessment resulting in rejection or an assessment resulting in acceptance. Such occasions are hereinafter referred to as "walk-away events". [0013] In such cases, the predetermined criteria preferably include the criterion that a walk-away event has occurred. [0014] Preferably, the criteria include the criterion that a number of assessments resulting in rejection exceeds a predetermined threshold number. [0015] For example, the number of assessments resulting in rejection may be the number of assessments resulting in rejection occurring within a predetermined window. The predetermined window is preferably a predetermined number of consecutive assessments. [0016] Alternatively, the predetermined window may be the most recent n assessments, where n is a predetermined number or a predetermined time interval. [0017] Preferably, for each assessment resulting in acceptance, the message includes data identifying a type of the token. [0018] The criteria preferably includes the criterion that the proportion of assessments resulting in acceptance of a particular type of token falls below a second predetermined threshold. [0019] For each assessment resulting in rejection, the message preferably includes data indicative of a reason for rejection. [0020] In a preferred embodiment, the processor outputs a signal when at least one of the criteria is satisfied; and an output device is provided which is responsive to the signal for outputting an alert signal. [0021] The alert signal is preferably output to an alert device adapted to attract the attention of an operator. The alert device may include, for example, a pager device, a mobile telephone, a public address system or a computer. [0022] Preferably, the criteria includes the criterion that a "token store full" event message or a "token store removal" is received. [0023] The system preferably includes a collating device for collating received data, for example in the form of a SQL database.

5 [0024] Preferably, the input device is adapted to receive messages from a plurality of validators included in respective machines and each message identifies the machine from which it is received. [0025] The input device is preferably adapted to poll the plurality of machines periodically for messages. [0026] Preferably, the system includes memory adapted to store a map indicating the location of each machine. The alert signal preferably then includes data identifying the location of the machine from which the message was received that gave rise to the alert signal. [0027] Preferably, the system further includes a user input device for enabling a user to interact with the system. [0028] In addition, the system is preferably adapted to poll the or each machine for meter information indicative of accumulated history of events. [0029] A second aspect of the invention provides a method of monitoring the performance of a validator for assessing a token, the method including the steps of: receiving messages containing data indicative of the following validator events: an assessment of a token resulting in acceptance; and an assessment of a token resulting in rejection; deriving timing information for the validator events from the messages; comparing the data and timing information with predetermined criteria; and determining walk-away events by comparing the timing information with the predetermined criteria, wherein walk-away events are occasions when an assessment resulting in rejection is followed by a period of greater than a predetermined threshold duration without an assessment resulting in rejection or an assessment resulting in acceptance, and wherein the processor is adapted to electronically store records of the determined walk-away events, acceptances, and rejections and to electronically generate an alert in response to determination of a selected criterion based on at least one walk-away event. [0030] The step of deriving the timing information preferably includes extracting timestamp information from the messages. [0031] Preferably, the step of deriving the timing information is performed with reference to the time of receipt of the messages by the input device. [0032] The messages are preferably indicative of the following validator events: 6 an assessment of a token resulting in acceptance; and an assessment of a token resulting in rejection. [0033] Preferably, the method further includes the step of determining walk-away events. In such cases, the predetermined criteria preferably include the criterion that a walk-away event has occurred. Alternatively, the predetermined criteria may include the criterion that greater than a predetermined threshold number of walk-away events have occurred. [0034] Preferably, the predetermined criteria include the criterion that a number of assessments resulting in rejection exceeds a predetermined threshold number. [0035] The method preferably further includes the step of outputting an alert signal when at least one of the predetermined criteria are satisfied. For example, the alert signal may be output to an alert device for attracting the attention of an operator. [0036] In the preferred embodiment, the method includes receiving messages from a plurality of validators included in respective machines. [0037] A third aspect of the invention provides a machine operable by a user providing a token, the machine including: a token validator for assessing the token and generating an internal acceptability message indicative of whether the token is acceptable; and an output device responsive to the internal acceptability message for outputting an external acceptability message to an external device, the external acceptability message including timestamp information indicative of the time of generation of the internal acceptability message and further containing data indicative of the following validator events: an assessment of a token resulting in acceptance; and an assessment of a token resulting in rejection; wherein the output device is adapted to determine walk-away events by comparing the timing information with the predetermined criteria, wherein walk-away events are occasions when an assessment of a token resulting in rejection is followed by a period of greater than a predetermined threshold duration without an assessment resulting in rejection or an assessment resulting in acceptance, and wherein the processor is adapted to electronically store records of the determined walk-away events, acceptances, and rejections and to electronically generate an alert in response to determination of a selected criterion based on at least one walk-away event. [0038] The machine preferably further includes a primary processor responsive to the internal acceptability message for implementing a primary function of the machine, 7 and the output device is disposed in a communications path between the validator and the primary processor, the output device allowing messages to pass through from the validator to the primary processor. [0039] Preferably, the external acceptability message preferably includes data indicative of a type of the token. [0040] In the event of a token being rejected, the external acceptability message preferably includes data indicative of the reason for rejection of the token. [0041] The machine preferably further includes a token storage device and the output device additionally outputs messages indicative of token storage device events. [0042] Preferably, the output device buffers the received internal acceptability messages and preferably outputs the buffered messages in response to a polling signal received from the external device. [0043] Preferably, the output device includes a network interface device for facilitating communication between the output device and the external device. [0044] In some embodiments, the primary function of the machine is to provide a game. In others, the primary function of the machine is to sell an item, for example a ticket. [0045] Preferably, the token is currency, for example a coin or preferably a banknote. [0046] A fourth aspect of the invention provides a validator monitoring device for inclusion in a machine operable by a user providing a token, the device including: an input device for receiving from a token validator for assessing the acceptability of tokens a validator event message containing data indicative of a validator event; and an output device responsive to the validator event message for outputting to an external device a further message including timestamp information indicative of the time that the validator event occurred and data indicative of the following validator events: an assessment of a token resulting in acceptance; and an assessment of a token resulting in rejection; wherein the output device is adapted to determine walk-away events by comparing the timing information with the predetermined criteria, wherein walk-away events are occasions when an assessment of a token resulting in rejection is followed by a period of greater than a predetermined threshold duration without an assessment 8 resulting in rejection or an assessment resulting in acceptance, and wherein the processor is adapted to electronically store records of the determined walk-away events, acceptances, and rejections and to electronically generate an alert in response to determination of a selected criterion based on at least one walk-away event. [0047] The device preferably further includes a buffer device for buffering received validator event messages for output to the external device. [0048] Preferably, said output device outputs the messages to the external device in response to a polling signal received from the external device. [0049] The device preferably further includes a pass-through channel for passing the validator event messages to a further device. [0050] A fifth aspect of the invention provides a method of monitoring a network including a plurality of machines having respective validators and a monitoring system, the method including the steps of: at the machines, generating messages including data indicative of validator events including at least one of acceptance and rejection of tokens; and at the monitoring system: receiving the messages at the monitoring system; for each message received at the monitoring system, deriving timing information for the respective validator event from the message, comparing the data with predetermined criteria wherein the predetermined criteria includes at least one timing-related criterion; and determining walk-away events by comparing the timing information with the predetermined criteria, wherein walk-away events are occasions when an assessment resulting in rejection is followed by a period of greater than a predetermined threshold duration without an assessment resulting in rejection or an assessment resulting in acceptance, and wherein the processor is adapted to electronically store records of the determined walk-away events, acceptances, and rejections and to electronically generate an alert in response to determination of a selected criterion based on at least one walk-away event. [0051] The method preferably further includes the step of, for each message received at the system, deriving timing information for the respective validator event, and wherein the predetermined criteria includes at least one timing-related criterion. [0052] The method preferably also includes the step of determining walk-away events, being occasions when an assessment of a token resulting in rejection is 9 followed by a period of greater than a predetermined threshold duration without an assessment resulting in acceptance or an assessment resulting in rejection. [0053] The method preferably includes: collating performance data for each machine; and manipulating numbers of walk-away events with reference to performance data of the machines. [0054] In a particular embodiment, the method includes: collating performance data for each machine; for each machine, determining a ranking as a function of at least one of: anticipated transactions over a predetermined time interval, number of walk-away events occurring at the machine, total number of walk-away events at machines in the system, and number of machines in the system; and prioritising maintenance of the machines in dependence upon the rankings. [0055] Furthermore, when monitoring a network in which each machine is a representative of one of a number of types of machine, the method may also include the steps of: collating performance data for each machine type; and determining the ranking in dependence upon at least one of: anticipated transactions by machine type; number of walk-away events by machine type. For example, the ranking for a machine of a particular type may be determined as a function of some or all of: the anticipated activity at that machine; the anticipated total activity at machines of that type; the number of machines of that type; the total number of machines; the number of walk-away events at that machine; and the total number of walk-away events at machines of that type. [0056] The general level of activity at machines in the system may also be a factor in the determining of the ranking.

9a [0057] Additionally or alternatively, the method may include the step of determining a respective predetermined threshold duration for each machine in dependence upon the respective machines' associated performance data or, where each machine is a representative of one of a number of types of machine, determining a respective predetermined threshold duration for each machine type in dependence upon the performance data for the respective machine types. [0058] In one embodiment of the method, the predetermined criteria include the criterion that, at one of the machines, greater than a predetermined threshold number of walk-away events have occurred. [0059] In a further embodiment, the method includes the steps of determining a respective predetermined threshold number of walk-away events for each machine in dependence upon the respective machines' associated performance data or, where each machine is a representative of one of a number of types of machine, determining a respective predetermined threshold number of walk-away events for each machine type in dependence upon the performance data for the respective machine types. [0060] According to a further aspect of the present invention there is provided a system for monitoring validators that assess payment tokens, the system including: an input device configured to receive messages from a plurality of interconnected machines including the validators, the messages containing data indicative of validator events occurring at the validators, the events including at least one of acceptance or rejection of the payment tokens; and a processor configured to: derive timing information for the validator events from the messages; maintain a record of the validator events and associated timing information for the validator events; assess relationships between sets of two or more of the validator events to determine whether predefined criteria is met for any of those sets of two or more of the validator events; perform a specified action in the case that at least one of the predefined criteria is met; wherein at least one of the predefined criteria includes determining walk-away events at the validators, and determine the walk-away events that represent occasions when an assessment of a token resulting in rejection is followed by a period of greater than a predetermined threshold duration without an assessment resulting in rejection or an assessment resulting in acceptance; and 9b wherein the specified action includes servicing one or more of the validators according to a prioritization of the one or more validators that is based on the walk-away events at the validators that are identified. [0061] According to a further aspect of the present invention there is provided a method of monitoring the performance of plural interconnected validators that are configured for assessing payment tokens, the method including: receiving messages containing data indicative of validator events at a processor, the validator events including at least one of acceptance or rejection of the payment tokens; deriving timing information for the validator events from the messages using the processor; maintaining a record of the validator events and associated timing information for the validator events in a memory; assessing relationships between sets of two or more of the validator events to determine whether predefined criteria is met for any of the sets of two or more of the validator events using the processor; performing a specified action in the case that at least one of the predefined criteria is met; and determining the criteria is met by identifying walk-away events using the processor, the walk-away events representing occasions when an assessment resulting in rejection is followed by a period of greater than a predetermined threshold duration without an assessment resulting in rejection or an assessment resulting in acceptance, wherein the specified action includes servicing the validators according to a prioritization of the validators that is based on the walk-away events at the validators that are identified. [0062] According to a further aspect of the present invention there is providedmethod of monitoring a network including a plurality of machines having respective validators and a monitoring system, the method including: generating messages including data indicative of validator events including at least one of acceptance or rejection of payment tokens; and at the monitoring system: receiving the messages; maintaining a record of the validator events and associated timing information for the validator events in a memory; 9c assessing relationships between sets of two or more of the validator events to determine whether predefined criteria is met for any of the sets of two or more of the validator events using a processor; performing a specified action in the case that at least one of the predefined criteria is met using the processor; and determining that the criteria is met by identifying walk-away events with the processor, the walk-away events representing occasions when an assessment of a token resulting in rejection is followed by a period of greater than a predetermined threshold duration without an assessment resulting in acceptance or an assessment resulting in rejection, wherein the specified action includes servicing the validators according to a prioritization of the validators that is based on the walk-away events at the validators that are identified. Brief Description of the Drawings [0063] A preferred embodiment of the invention will now be described, by way of example only, with reference to the accompanying drawings in which: [0064] Figure 1 is a schematic overview of a network including a system for monitoring validators that assess tokens and a plurality of machines operable by respective users by providing tokens; [0065] Figure 2 is a more detailed schematic representation of the system for monitoring validators shown in Figure 1; -10 Figure 3 is a more detailed schematic representation of a first embodiment of a machine operable by a user providing a token shown in Figure 1; Figure 4 is a more detailed schematic representation of a second embodiment of a machine operable by a user providing a token; 5 Figure 5 is a more detailed schematic representation of a third embodiment of a machine operable by a user providing a token; Figure 6 is a more detailed schematic representation of a fourth embodiment of a machine operable by a user providing a token; Figure 7 is a detail of a first graphical report that may be produced by the system shown in 10 Figure 1; Figure 8 is a second graphical report that may be produced by the system shown in Figure 1; and Figure 9 is a schematic representation of a device for inclusion in a machine operable by a user provided with a token. 15 DETAILED DESCRIPTION Figure 1 shows a network including a system in the form of a host computer 1 for monitoring validators that assess tokens, and a plurality of electronic gaining machines 2 operable by respective users providing tokens. The host 1 and the machines 2 communicate via internal or, as shown, external communications devices 3 in a known way. For example, various 20 embodiments effect communication via Ethernet, wireless Ethernet, bluetooth, or telephony networks or combinations of these types of network. In a preferred embodiment, communication between the host and the machines occurs via a 9600-baud 8N1 RS485 multi drop network using CRC checking. The host 1 is shown in more detail in more detail in Figure 2. It includes an input device 4 25 for receiving messages 5 from a machine 2 including a validator 6, the messages containing data indicative of validator events. The host further includes a processor 7, having associated memory 8, for deriving timing information for the validator events and for comparing the data and timing information with predetermined criteria. When at least one of the criteria is satisfied, the processor 7 outputs a signal to an output device 9. The output device 9 responds to the 30 signal by outputting an alert signal 10. Figure 3 shows a first example of a machine 2 operable by a user providing a token, in this example a banknote. The machine includes a validator 6 for assessing the banknote and -11 generating an internal acceptability message indicative of whether the banknote is acceptable. A primary processor I1 is responsive to the internal acceptability message for implementing a primary function of the machine. An output device 12 is responsive to the internal acceptability message for outputting in real time an external acceptability message 13 to an external device, 5 for example the host 1 shown in Figure 2. The host input device 4 is adapted to poll the plurality of machines 2 in sequence periodically. Messages are received from each machine 2 at which a validator event has occurred during the preceding polling interval. Each message identifies the machine 2 at which it is generated, by including addressing information for the machine 2, the network card 3, the 10 validator 6 or the output device 12 for example. The processor 7 derives timing information for the validator events with reference to the time of receipt of the messages by the input device 4. For example, if the polling interval is I second and a polling sequence begins at 14:36:04, all messages received during that polling sequence are considered to have been received at 14:36:04. The validator events which gave 15 rise to the messages are also considered to have occurred at 14:36:04. Alternatively, if it is known that generation and processing of messages by the machines 5 takes, say, 3 seconds, then 3 seconds may be subtracted from this time. When an accuracy of greater than I second is required, a shorter polling interval is used. Where necessary when using short-polling intervals with networks having a large number of machines 2, a plurality of communications paths are 20 used to ensure that the polling interval may be maintained. A further example of a machine 2' operable by a user providing a token is shown in Figure 4. This example includes a token validator 6 for assessing the token, again a banknote in this example, and outputting an internal acceptability message indicative of whether the banknote is acceptable. A primary processor 11 is responsive to the internal acceptability 25 message for implementing a primary function of the machine. An output device 12' is responsive to the internal acceptability message for outputting an external acceptability message 13 to an external device. In this example, which is particularly adapted for use in networks in which a high degree of temporal resolution is required, the external acceptability message 13 includes time stamp information indicative of the time of generation of the internal 30 acceptability message. The time stamp information is added to the message by a time stamping device 14. In one embodiment, absolute time stamps are used indicating absolutely the time of generation of the message. However, in alternative embodiments, relative time stamps are used, - 12 including an offset value indicating the time offset from a reference point, for example, the time of the last polling of the machine 2. When used in combination with one or more machines 2' of this type, the host processor 7 derives the timing information by extracting the time stamp information from received 5 messages. In embodiments using relative time stamps, the host computer derives the time of generation of the messages with reference both to the time stamp information and to internal information relating to the timing of the polling of the machines. In the embodiment shown in Figure 4, the machine primary processor 11 also outputs messages relating to the game being played on the gaming machine in a manner well-known to 10 those in the field of networking gaming machines. In one embodiment, the primary processors 11 of the gaming machines 2 are linked using a network separate from the network provided for monitoring validator activity. However, in another embodiment, the same network is used for both purposes. In one such embodiment, the primary processors I I use network cards separate from those provided for the output devices 12'. In an alternative embodiment, the 15 output devices and the primary processors share network cards. While this feature has been described with reference to the machine shown in Figure 4, it is equally applicable to that shown in Figure 3. As shown in Figures 3 and 4, the output device 12' is disposed in a communications path between the validator 6 and the primary processor 11. It allows messages from the validator to 20 pass through to the primary processor and also buffers the messages for output to the host 1. In an alternative embodiment, for use in networks in which polling is likely to be at least as frequent as generation of event messages, an output device is used that only stores the most recently generated event message for output to the host. The output device 12' outputs buffered or stored messages in response to the polling signal 25 received from the extemal device. In the preceding examples of machines shown in Figures 3 and 4, the output device is shown as being distinct from the validator 6 and the primary processor 11. However in one embodiment, shown in Figure 5, the output device 12 is integral with the validator 6'. In another embodiment, shown in Figure 6, the output device 12 is integral with the primary 30 processor 11'. As indicated above, validator events that cause the generation of validator event messages include assessments of banknotes resulting in acceptance and assessments of banknotes resulting in rejection. The machines 2 also include respective token storage devices in the form of note -13 stackers 15. Storage device events such as the removal of the note stacker 15 or the storage of insertion of a note into the stacker resulting in the stacker being full also cause the generation of a validator event message containing information indicative of the storage device event. In addition to the information identifying the machine that generated the message, and the 5 time stamp information in the case of machines 2' described above with reference to Figure 4, each validator event message includes: * Information indicative of the type of event: for example, assessment of a token resulting in acceptance (acceptance message), assessment of a token resulting in rejection (rejection message), removal of the note stacker, the note stacker 10 becoming full. * Further information relating to the event: in the case of an acceptance message, the type of the token, for example, the denomination of the banknote; in the case of a rejection message, the reason for the rejection (for example, failed optical/magnetic test, note jam). 15 The host 1 includes a data collating device in the form of a SQL database 16 for collating the data from the received valid ator event messages. Upon receiving validator event messages, the host processor 7 stores the data in the database 16. In one embodiment, after processing each received message, the processor checks whether the stored data satisfies any of the criteria for generation of an alert message. In other embodiments, this step is performed once at the end 20 of each polling period. In yet further embodiments, the checking is performed periodically and separately from the polling of the machines. The host I also stores in the database 16 or other memory 8 information relating to the various criteria against which the stored data is to be checked to determine whether an alert signal is to be generated. A first broad category of criterion for generation of an alert message 25 includes the criterion that a number of assessments resulting in rejection exceeds a predetermined threshold. In one embodiment, assessments occurring within a predetermined window of a predetermined number of consecutive assessments of an inserted banknote are considered. For example, for each machine 2 the processor 7 checks the most recent 100 assessments and an alert signal is generated if the number of rejections is greater than a 30 predetermined threshold of 10, that is that acceptance has dropped below 90%. Different thresholds, for example representing acceptance rates of 80%, 70%, 60% and so on, and windows of different sizes, for example 50, 200, 500 or 1000 assessments, are used as - 14 appropriate, according to preference. This type of criterion may be of assistance particularly in identifying validators whose ability to identify correctly inserted banknotes is declining. In another embodiment, assessments occurring within a predetermined time interval are considered. In this embodiment, for each machine 2 the processor 7 checks assessments within 5 a time interval, for example, the preceding 15 minutes, and an alert signal is generated if the number of rejections is greater than a predetermined threshold of 2. This type of criterion may be of assistance particularly in identifying a machine 2 at which a user requires assistance, for example because they are not aware that a token that they are attempting repeatedly to insert is invalid-such as the wrong type of card or a counterfeit banknote. It may also be of assistance 10 in identifying a machine at which a user is attempting to launder counterfeit banknotes. A second category of criterion includes the criterion that the proportion of assessments at a particular machine 2 resulting in acceptance of a particular type of token falls below another threshold. For example, if the proportion of acceptances that relate to $10 notes falls below a threshold value, this may be indicative of a decline in a particular validators ability to identify 15 $10 notes correctly. In some embodiments, the threshold is determined with reference to the proportions of the various denominations being accepted at all machines. In other embodiments, the threshold is determined with reference to historical data, for example relating to the typical proportions expected at a particular time of day. A further broad category of criterion includes the consideration of walk-away events. A 20 walk-away event is defined as an occasion when an assessment of a token resulting in rejection of that token is followed by a period of greater than a predetermined threshold duration without an assessment resulting in rejection or an assessment resulting in acceptance. In some embodiments, a more limited definition may be used: i.e. a walk-away event is an occasion when a series of greater than a predetermined number of assessments resulting in rejection of a 25 token occurs within a predetermined time interval, and the series of assessments resulting in rejection is followed by a period of greater than a predetermined threshold duration without an assessment resulting in rejection or an assessment resulting in acceptance. Such events are of interest since, in a retail or gaming scenario, they may be indicative of lost revenue in that an intended user of a machine has attempted to effect a transaction, but has 30 been prevented by the validator. On some such occasions, the user may use another machine, resulting in no loss of revenue, but perhaps in irritation to the user. On other such occasions, however, the result may be that the user abandons the attempted transaction altogether. In other scenarios, for example automated ticket sales at transport stations, the walk-away events may - 15 result in increased demand on manned sales points. Increasing the need for such points, and their associated cost. The processor 7 also checks whether a message has been received indicating that a note stacker 15 is full or that it has been removed. Such criteria may assist staff at a venue to identify 5 machines 2 that require attention-for example, emptying of the note stacker 15--or to have greater information to monitor the emptying of note stackers 15 by noting the precise time a stacker is removed. A user input device 17, for example a keyboard and/or a mouse in combination with a graphical user interface, is provided for enabling a user having a password to interact with the 10 system, add or modify the various criteria and thresholds and the destinations of alert signals, and add, modify or remove details of particular machines 2. The input device 17 is also used by a user to access various reports. Reports available to a user include graphs for each machine 2 representing acceptance or rejection proportions against time, including proportions over various time intervals a detail of one of which is shown in Figure 7 and lists of machines 2 which are 15 offline. Other reports include lists of machines 2 that are performing above or below respective general or machine-specific criteria, for example acceptance percentages, including information indicative of actual performance. In a particular embodiment, these lists are limited to machines 2 at which more than a predetermined threshold number of assessments have been made, to avoid undue attention being paid to machines 2 for which the amount of available data 20 is statistically insignificant. This threshold may be set by the user. Figure 8 shows a further report in the form of a scatter graph showing the acceptance proportions for each machine in a network. A number of examples of methods of monitoring walk-away events will now be provided with reference to a gaming establishment having thirty gaming machines each having respective 25 validators and each interconnected in a manner described above. General performance data for the various machines is collated in manner known to those skilled in the art. Furthermore, performance data for the validators in the machines is collated in a manner described above. Over a period of one week, the walk-away events occurring are summarised in the following table: 30 -16 Machine # Event Time 11 07/02/2006 1:23:26PM 1 07/02/2006 8:39:21 PM 19 07/02/2006 9:02:08 PM 9 08/02/2006 10:53:40 PM 17 08/02/2006 11:32:50PM 16 09/02/2006 5:50:07 PM 16 08/02/2006 7:01:55 PM a 08/02/2006 8;12;54 PM 30 08/02/2006 8:16:16 PM 28 09/02/2006 7:30:07 PM 24 09/02/2006 9:07:20 PM 9 09/02/2006 10:36:33 PM 17 09/02/2006 10:36:50 PM 20 09/02/200610:55:04 PM 12 09/02/2006 11 :10:52PM 17 10/02/2006 3:00:40 PM 20 10/02/2006 5:07:13PM 28 10/02/2006 5-57:06 PM 1 10/02/2006 6:41:26 PM 30 10/02/2006 6:50:53 PM 26 10/02/2006 9:05:00 PM 24 10/02/2006 9:13:25 PM 29 10/02/2006 9:20:29 PM 6 10/02/2006 9:22:38 PM 13 10/02/200610:02:26 PM 30 11/02/2006 12:12:49 AM 3 11/02/2006 12:46:30 AM 30 11/02/2006 11:21:44 AM 9 11/02/2006 11:45:15 AM 30 11/02/2006 4:08:33 PM 6 11/02/2006 6:16:52 PM 19 12/02/2006 1:01:15 AM 8 12/02/2006 5:05:56 PM 24 12/02/2006 5:07:12PM 4 12/02/2006 6:14:00 PM Table 1: Walk-Away Events In a simple embodiment, an operator is alerted when a walk-away event occurs, or when the number or frequency of walk-away events occurring at a particular machine reaches a - 17 predetermined threshold value. However, other embodiments provide more sophisticated methods of considering walk-away events. In one such embodiment, the total number of walk-away events in a specified time interval in a venue having a number of machines is monitored. An example of this is shown in the 5 following table: Date Walk-Away Events 07/02/2006 3 08/02/2006 6 09/02/2006 6 10/02/2006 10 11/02/2006 6 12/02/2006 4 13/0212006 0 Total 35 Table 2: Walk-Away Events by date Such information may be correlated with information relating to general activity in a venue. The tracking of walk-away events during a specified time interval in this way may allow an operator to identify peaks in walk-away activity, which may be indicative of attempted use of 10 counterfeit currency, particularly where peaks in walk-away activity do not correspond with peaks in general activity. In another embodiment, the number of walk-away events is monitored by machine. This is illustrated in Table 3 below: -18 Machine Machine Walk-Away # type Events 1 A 2 3 B 1 4 C I 6 D 2 8 B 2 9 r. 3 11 F 1 12 G 1 13 H I 16 I 2 17 J 3 19 K 2 20 K 2 24 L 3 26 M I 28 K 2 29 N 1 30 J 5 Table 3: Walk-Away Events by Machine In this way, it may be readily seen which machines are suffering the greatest number of walk-away events. This information may be used for the purposes of prioritising the 5 maintenance of the validators (e.g. replacement or repair). More sophisticated method of prioritising maintenance are described below. In a first such method, regard is had to the number of transactions expected at a particular machine in a specified time period. This information may be derived, for example, from historical data relating to activity at the various machines. Since it is likely that priority should 10 be given to machines having large numbers of anticipated transactions in a given time interval (say, one hour) and large numbers of walk-away events in a time interval, multiplying these two factors may result in a figure by which the machines may be prioritised for maintenance. An example of this is given in Table 4, below: - 19 Antipated transactions ul Machine Anticipated iransaciions Walk-A way machine x # # at machina/hour Events walk-away events 30 16 5 80 24 19 3 57 1 17 2 34 17 - 11 3 33 19 15 30 6 14 2 28 16 14 2 28 20 13 2 26 9 7 3 21 13 16 16 29 16 16 3 15 15 8 7 2 14 12 12 1 12 11 10 1 10 26 2 1 2 2 18 0 0 4 0 1 0 5 0 0 7 8 0 0 10 11 0 0 14 18 0 0 15 11 0 0 18 6 0 0 21 0 0 0 22 7 0 0 23 5 0 0 25 8 0 0 27 5 0 0 28 0 2 0 Table 4: Machines ranked for maintenance by Walk-Away Events x anticipated transactions per hour In some contexts, for example in gaming venues, the machines connected to a system may each be examples of a particular machine type. In a gaming venue, each machine provides a 5 particular game, and the various games may have varying degrees of popularity. Table 5 below shows the machines ranked according to the product of the number of walk-away events at the -20 respective machines and the anticipated total number of transaction at the type of machine. The anticipated total number of transactions at a particular machine type may again be derived from historical activity data. Anticipated transactions Machine Machine Anticipated transactions WalkAway at machine type x # # type at machine typehour Events walk-away events 30 27 5 135 17 J 27 3 81 I A 35 2 70 6 D 30 -2 60 24 L 19 3 57 19 K 28 2 56 20 K 28 2 56 28 K 28 2 56 8 B 23 2 46 13 14 34 1 34 12 0 29 1 29 16 1 14 2 28 3 a 23 1 23 9 E 7 3 21 29 N 21 1 21 11 F 18 1 18 4 C 15 1 15 26 M 2 1 2 2 A 35 0 0 5 a 23 0 0 7 C 15 0 0 10 D 30 0 0 14 H 34 0 0 15 G 29 0 0 18 G 29 0 0 21 K 28 0 0 22 C 15 0 0 23 D 30 0 0 25 F i 0 0 27 N 21 0 0 Table 5: Machines ranked for maintenance by Walk-Away Events x anticipated transactions per hour at machine type 5 In a final example, it may be that the various machine types have varying popularity and that particular machines within a machine type also have varying degrees of popularity. Table 6 below therefore shows the machines ranked by the product of the anticipated number of -21 transactions at a particular machine (to take account of the popularity of that specific machine), the total number of transactions at the machine type (to take account of the relative popularities of the machine types), and the number of walk-away event occurring at the machines. Anticipated transaclians at Anticipated Walk machine x anticipated Machine Machine Anticipated transactions transactions at machine Away transactions as machine # type at machine/hour typelhour Events type x # walk-away events 30 J 16 27 5 2160 A 17 35 2 1190 24 L 19 19 3 1083 17 1 11 27 3 891 6 D 14 30 2 840 19 K 15 28 2 840 20 K 13 28 2 728 13 H 16 34 1 544 16 1 14 14 2 392 12 G 12 29 1 348 3 B Is 23 1 345 29 N 16 21 1 336 8 B 7 23 2 322 11 F 10 18 1 10 9 E 7 7 3 147 26 M 2 2 1 4 2 A 18 35 0 0 4 C 0 15 1 0 5 B 1 23 0 0 7 C 8 15 0 0 10 D 11 30 0 0 14 H 18 34 0 0 15 G 11 29 0 0 Is 0 6 29 0 0 21 K 0 29 0 0 22 C 7 15 0 0 23 D 5 30 0 0 25 F 8 18 0 0 27 N 5 21 0 0 21 K 0 28 2 0 Table 6: Machines ranked for maintenance by Walk-Away Events x anticipated transactions per hour at machine type x 5 landcipated transactions pvr hour at machine -22 The above examples are each examples of a more general strategy of ranking the gaming machines by a factor determined as a function of various parameters. The ranking factor for a particular machine, R,, may be generalised as: R -f (A,. A(Tj), n(T). n, Wi, W(T)) 5 where A, is the anticipated activity (e.g. number of transactions) at a particular machine in a predetermined time interval, A(T,) is the anticipated total activity at machines of the same type as the particular machine during the same predetermined time interval, n(T,) is the total number of machines of the same type as the particular machine, n is the total number of machines in the network, WJ is the number of walk-away events at the particular machine in a specified time 10 interval, and W(T) is the total number of walk-away events at machines of the same type as the particular machine in the same time interval. In the above examples, the coefficients or exponents of some of the parameters are zero while others are 1. Other strategies are possible in which the coefficients or exponents take other values. For example, it may be determined that a machine should be considered a lower 15 priority if it is of a type of which there are a number of examples in the system: n(T) may therefore have a negative exponent. However to take account of user preferences for a particular machine regardless of the availability of others of the same type, the exponence may have an absolute value of less than one: e.g. -0.5. The strategy appropriate for a particular network may also depend upon various other 20 factors such as overall activity in a system. For example, in a gaming venue where activity is approaching the total capacity of the venue, the existence of more than one machine of a type will be of less relevance, since an intended user of a particular machine may find no other examples of that machine type available to him. Conversely, where overall activity is low, a user may easily find another example of a particular machine type. 25 Scheduling of maintenance may be automated to some extent by use of the system described above, and messages may be sent to a pager or other communications device as described above, specifying the next machine on which maintenance is to be performed. As indicated above, walk-away events are occasions on which an assessment of a token resulting in rejection of that token is followed by a period of greater than a predetermined 30 threshold duration without an assessment resulting in rejection or an assessment resulting in acceptance. In one embodiment, in which the definition of a walk-away event is intended as closely as possible to reflect the actual occurrences of a user attempting to insert a token into -23 validator and abandoning the attempt after a rejection, the predetermined threshold duration is fixed, and is identical for all machines. For example, two minutes may be appropriate. However, in addition to or as an alternative to the methods described above of considering walk-away events and managing the varying popularity of machines and machine types, the 5 predetermined threshold duration may differ for different machines or machine types. Furthermore, the predetermined threshold durations may change depending upon general levels of activity or anticipated levels of activity. Different levels of security may be used in a known way for example to allow some users to view database reports while preventing modification of criteria, thresholds and so on. 10 The database 16 also includes information identifying other characteristics of the machines 2, for example the game being provided by the machines 2, current status-online or offline, identification numbers of the machines 2, and the location of the various machines 2. In one embodiment, this location information is purely textual, However, in other embodiments, images such as floor plans and image/text combinations are used. 15 When one of the criteria for generation of an alert signal is satisfied, the processor 7 sends a signal to the output device 9, which responds by sending the alert signal to an alert device 8 adapted to attract the attention of an operator. Various types of alert device 18 are used in various embodiments, including pager devices, mobile telephones using SMS or automated voice calls, public address systems, computer devices using email or network alerts, and so on. 20 The alert signal identifies the machine 2 giving rise to the alert signal, including textual and/or graphical information about the location of the machine 2. The signal also includes information indicative of the reason for the alert signal. In a particular embodiment, alert signals generated in response to different types of criteria are sent to different alert devices 18 to attract the attention of different personnel. For example with reference to Figure 7, a spike in 25 the number of rejections occurring over a short time might cause a signal to be sent to a device to alert customer service and/or security personnel; the proportion of rejections within a preceding number of insertions of banknotes rising above a threshold or a note jam might cause a signal to be sent to a device 18 to alert maintenance personnel. For testing purposes, an alert signal may be sent simply when a note is accepted or rejected, for example after maintenance of 30 a validator 6. An alert signal may also be sent when a note of a particular denomination is accepted, for example a high value note, or when tampering with the validator is detected. To provide further data, the host I may upon request of a user and/or periodically poll the various machines 2 for meter information indicative of the total number of acceptances and -24 rejections of various denominations, for example, since the last poll or some other reference point, as an indication of the history of events. This information may be retrieved from memory in the output devices or from the validators themselves. This may be of assistance in rapidly recommencing monitoring in the event that the host computer is offline for a period. 5 Turning to Figure 9, a particular embodiment provides separately a validator monitoring device 12', equivalent to the output device 12 described above, for inclusion in a machine operable by a user provided with a token. The device includes an input device 19 for receiving from a token validator for assessing the acceptability of tokens a validator event message 20 containing data indicative of a validator event. An output device 21 is responsive to the 10 validator event message for outputting a further message 22 in real time to an external device such as the host I for example via a network as described above with reference to Figure 1. Such a monitoring device 12' may be retrofitted to an existing machine to allow its validator 6 to be monitored as described above. In a particular embodiment, the further message 22 includes time stamp information indicative of the time the validator event occurred. In one 15 embodiment, this time stamp information is received in the validator event message 20 and simply passed through the device 12'. In another embodiment, the device 12' inserts the time stamp information into the message. In embodiments in which the device itself adds the time stamp information, the outputting of the further message need not be in real time. The device 12' further includes a buffer device 23 for buffering received validator event 20 messages 20 for output to the external device. The output device 21 outputs the messages 22 to the external device in response to a polling signal received from the external device, as described above. In a particular embodiment, the device 12' is intended to be inserted into the machine in the communications path between the validator 6 and the primary processor 11 of the machine. 25 In such cases, the device 12' further includes a pass-through channel 24 for passing the validator event messages 20 to the machine primary processor 11. In addition to monitoring individual validators, the invention also finds application in the monitoring of a network of machines. For example, it is known to monitor the turnover of various gaming machines to identify favoured locations on a gaming floor or to identify popular 30 games. Manipulation of the machine performance data with reference to validator performance data may assist in formulating accurate conclusions from the machine performance data. For example, a machine which has low turnover but which also has a low acceptance rate may be omitted from consideration of the popularity of the game being provided by that machine.

-25 Additionally or alternatively, gaming floor locations at which acceptance levels are consistently low may be identified as requiring additional security measures. Although the invention has been described primarily with reference to its application in networks of electronic gaming machines, it will be clear to those skilled in the art that it also 5 finds application many other forms. In particular, the invention finds application in connection with other machines, for example vending machines for confectionery or tickets, and ticket or card-operated gates and so on. Furthermore, features of the various described examples may be provided in any combination. Additionally, the various functionalities have been described as being performed by 10 distinct devices, such as integrated circuits. However, in preferred embodiments, all or any combination of functionalities may instead be performed by multi-purpose integrated circuits or implemented in software executed by a processor. Particularly in such cases, the invention may additionally be embodied in a computer program or in a computer program in a data signal or stored on a data carrier. 15

Claims (34)

1. A system for monitoring a validator that assesses a token, the system including: an input device for receiving messages from a machine including a validator, the messages containing data indicative of validator events; and a processor for deriving timing information for the validator events from the messages and for comparing the data and timing information with predetermined criteria; wherein the input device is adapted to receive messages indicative of the following validator events: an assessment of a token resulting in acceptance; and an assessment of a token resulting in rejection; and wherein the processor is adapted to determine walk-away events by comparing the timing information with the predetermined criteria, wherein walk-away events are occasions when an assessment of a token resulting in rejection is followed by a period of greater than a predetermined threshold duration without an assessment resulting in rejection or an assessment resulting in acceptance, and wherein the processor is adapted to electronically store records of the determined walk-away events, acceptances, and rejections and to electronically generate an alert in response to determination of a selected criterion based on at least one walk-away event.

2. A system according to claim 1, wherein the predetermined criteria include the criterion that a walk-away event has occurred.

3. A system according to claim 1, wherein the criteria include the criterion that a number of assessments resulting in rejection exceeds a predetermined threshold number.

4. A system according to any one of the preceding claims, wherein the input device is adapted to receive messages from a plurality of validators included in respective machines and wherein each message identifies the machine from which the message is received.

5. A method of monitoring the performance of a validator for assessing a token, the method including the steps of: receiving messages containing data indicative of the following validator events: 27 an assessment of a token resulting in acceptance; and an assessment of a token resulting in rejection; deriving timing information for the validator events from the messages; comparing the data and timing information with predetermined criteria; and determining walk-away events by comparing the timing information with the predetermined criteria, wherein walk-away events are occasions when an assessment resulting in rejection is followed by a period of greater than a predetermined threshold duration without an assessment resulting in rejection or an assessment resulting in acceptance, and wherein the processor is adapted to electronically store records of the determined walk-away events, acceptances, and rejections and to electronically generate an alert in response to determination of a selected criterion based on at least one walk-away event.

6. A method according to claim 5, wherein the predetermined criteria include the criterion that a walk-away event has occurred.

7. A method according to claim 5, wherein the criteria include the criterion that a number of assessments resulting in rejection exceeds a predetermined threshold number.

8. A method according to any one of claims 5 to 7, including the step of: outputting an alert signal when at least one of the predetermined criteria are satisfied.

9. A method according to any one of claims 5 to 8, including receiving messages from a plurality of validators included in respective machines.

10. A machine operable by a user providing a token, the machine including: a token validator for assessing the token and generating an internal acceptability message indicative of whether the token is acceptable; and an output device responsive to the internal acceptability message for outputting an external acceptability message to an external device, the external acceptability message including timestamp information indicative of the time of generation of the internal acceptability message and further containing data indicative of the following validator events: 28 an assessment of a token resulting in acceptance; and an assessment of a token resulting in rejection; wherein the output device is adapted to determine walk-away events by comparing the timing information with the predetermined criteria, wherein walk-away events are occasions when an assessment of a token resulting in rejection is followed by a period of greater than a predetermined threshold duration without an assessment resulting in rejection or an assessment resulting in acceptance, and wherein the processor is adapted to electronically store records of the determined walk-away events, acceptances, and rejections and to electronically generate an alert in response to determination of a selected criterion based on at least one walk-away event.

11. A validator monitoring device for inclusion in a machine operable by a user providing a token, the device including: an input device for receiving from a token validator for assessing the acceptability of tokens a validator event message containing data indicative of a validator event; and an output device responsive to the validator event message for outputting to an external device a further message including timestamp information indicative of the time that the validator event occurred and data indicative of the following validator events: an assessment of a token resulting in acceptance; and an assessment of a token resulting in rejection; wherein the output device is adapted to determine walk-away events by comparing the timing information with the predetermined criteria, wherein walk-away events are occasions when an assessment of a token resulting in rejection is followed by a period of greater than a predetermined threshold duration without an assessment resulting in rejection or an assessment resulting in acceptance, and wherein the processor is adapted to electronically store records of the determined walk-away events, acceptances, and rejections and to electronically generate an alert in response to determination of a selected criterion based on at least one walk-away event.

12. A method of monitoring a network including a plurality of machines having respective validators and a monitoring system, the method including the steps of: at the machines, generating messages including data indicative of validator events including at least one of acceptance and rejection of tokens; and at the monitoring system: 29 receiving the messages at the monitoring system; for each message received at the monitoring system, deriving timing information for the respective validator event from the message, comparing the data with predetermined criteria wherein the predetermined criteria includes at least one timing-related criterion; and determining walk-away events by comparing the timing information with the predetermined criteria, wherein walk-away events are occasions when an assessment resulting in rejection is followed by a period of greater than a predetermined threshold duration without an assessment resulting in rejection or an assessment resulting in acceptance, and wherein the processor is adapted to electronically store records of the determined walk-away events, acceptances, and rejections and to electronically generate an alert in response to determination of a selected criterion based on at least one walk-away event.

13. A method according to claim 12, including: collating performance data for each machine; for each machine, determining a ranking as a function of at least one of: anticipated transactions over a predetermined time interval, number of walk-away events occurring at the machine, total number of walk-away events at machines in the system, and number of machines in the system; and prioritizing maintenance of the machines in dependence upon the rankings.

14. A method according to claim 13, for monitoring a network in which each machine is a representative of one of a number of types of machine, including the steps of: collating performance data for each machine type; and determining the ranking in dependence upon at least one of: anticipated transactions by machine type; number of walk-away events by machine type.

15. A method according to claim 12, including the steps of: collating performance data for each machine; and 30 determining a respective predetermined threshold duration for each machine in dependence upon the respective machines' associated performance data.

16. A method according to claim 12, including the steps of: collating performance data for each machine; and determining a respective predetermined threshold number of walk-away events for each machine in dependence upon the respective machines' associated performance data.

17. A method according to any one of claims 12 to 16, wherein the predetermined criteria include the criterion that, at one of the machines, greater than a predetermined threshold number of walk-away events have occurred.

18. A system for monitoring validators that assess payment tokens, the system including: an input device configured to receive messages from a plurality of interconnected machines including the validators, the messages containing data indicative of validator events occurring at the validators, the events including at least one of acceptance or rejection of the payment tokens; and a processor configured to: derive timing information for the validator events from the messages; maintain a record of the validator events and associated timing information for the validator events; assess relationships between sets of two or more of the validator events to determine whether predefined criteria is met for any of those sets of two or more of the validator events; perform a specified action in the case that at least one of the predefined criteria is met; wherein at least one of the predefined criteria includes determining walk away events at the validators, and determine the walk-away events that represent occasions when an assessment of a token resulting in rejection is followed by a period of greater than a predetermined threshold duration without an assessment resulting in rejection or an assessment resulting in acceptance; and 31 wherein the specified action includes servicing one or more of the validators according to a prioritization of the one or more validators that is based on the walk-away events at the validators that are identified.

19. A system according to claim 18, wherein the predefined criteria include a criterion that a walk-away event has occurred.

20. A system according to claim 18 or 19, wherein the input device is adapted to receive the messages that are indicative of the validator events that include: an assessment of a token resulting in acceptance; and an assessment of a token resulting in rejection.

21. A system according to claim 20, wherein the predefined criteria include a criterion that a number of assessments resulting in rejection exceeds a predetermined threshold number.

22 A system according to any one of claims 18 to 21, wherein the input device is adapted to receive the messages from the validators included in respective machines and wherein the messages identify the machine from which the messages are received.

23. A method of monitoring the performance of plural interconnected validators that are configured for assessing payment tokens, the method including: receiving messages containing data indicative of validator events at a processor, the validator events including at least one of acceptance or rejection of the payment tokens; deriving timing information for the validator events from the messages using the processor; maintaining a record of the validator events and associated timing information for the validator events in a memory; assessing relationships between sets of two or more of the validator events to determine whether predefined criteria is met for any of the sets of two or more of the validator events using the processor; performing a specified action in the case that at least one of the predefined criteria is met; and 32 determining the criteria is met by identifying walk-away events using the processor, the walk-away events representing occasions when an assessment resulting in rejection is followed by a period of greater than a predetermined threshold duration without an assessment resulting in rejection or an assessment resulting in acceptance, wherein the specified action includes servicing the validators according to a prioritization of the validators that is based on the walk away events at the validators that are identified.

24. A method according to claim 23, wherein the predefined criteria include a criterion that a walk-away event has occurred.

25. A method according to claim 23 or 24, wherein the messages are indicative of the validator events that include: an assessment of a token resulting in acceptance; and an assessment of a token resulting in rejection.

26. A method according to claim 25, wherein the predefined criteria include the criterion that a number of assessments resulting in rejection exceeds a predetermined threshold number.

27. A method according to any one of claims 23 to 26, further including: outputting an alert signal when at least one of the predefined criteria are satisfied.

28. A method according to any one of claims 23 to 27, including receiving the messages from a plurality of the validators that are included in respective machines.

29. A method of monitoring a network including a plurality of machines having respective validators and a monitoring system, the method including: generating messages including data indicative of validator events including at least one of acceptance or rejection of payment tokens; and at the monitoring system: receiving the messages; maintaining a record of the validator events and associated timing information for the validator events in a memory; 33 assessing relationships between sets of two or more of the validator events to determine whether predefined criteria is met for any of the sets of two or more of the validator events using a processor; performing a specified action in the case that at least one of the predefined criteria is met using the processor; and determining that the criteria is met by identifying walk-away events with the processor, the walk-away events representing occasions when an assessment of a token resulting in rejection is followed by a period of greater than a predetermined threshold duration without an assessment resulting in acceptance or an assessment resulting in rejection, wherein the specified action includes servicing the validators according to a prioritization of the validators that is based on the walk away events at the validators that are identified.

30. A method according to claim 29, including, for the messages received at the system, deriving timing information for the validator events associated with the messages, and wherein the predefined criteria includes at least one timing related criterion.

31. A method according to claim 29 or 30, including: collating performance data for the machines; for the machines, determining a ranking as a function of at least one of: anticipated transactions over a predetermined time interval, a number of the walk-away events occurring at the machine, a total number of the walk-away events at the machines in the system, and a number of the machines in the system; and prioritizing maintenance of the machines in dependence upon the rankings.

32. A method according to claim 31, for monitoring the network in which the machines are representative of types of machines, the method further including: collating performance data for the types of machines; and determining the ranking in dependence upon at least one of: anticipated transactions by the types of machines; 34 a number of the walk-away events by the types of machines.

33. A method according to claim 29 or 30, including: collating performance data for the machines; and determining a respective predetermined threshold duration for the machines in dependence upon performance data associated with the machines.

34. A method according to any one of claims 29 to 33, wherein the predetermined criteria include a criterion that, at one or more of the machines, a greater than a predetermined threshold number of the walk-away events has occurred.