WO2014128064A1

WO2014128064A1 - A time and attendance processing system

Info

Publication number: WO2014128064A1
Application number: PCT/EP2014/052958
Authority: WO
Inventors: Kumar Sunil; Brendan Feeney; Margaret FEENEY; Linda O'REILLY
Original assignee: Chennai Research Limited
Priority date: 2013-02-21
Filing date: 2014-02-14
Publication date: 2014-08-28
Also published as: GB201514739D0; GB2525129A

Abstract

A time and attendance processing system has multiple terminals (1) with employee verification capability, and they may be distributed over a wide geographical area. There is at least one server (3), which may be a cloud-based virtual server. The terminals send in real time a record in response to an event (F1 – F8) marking start or end of an activity. The server (3) receives the event records and performs initial processing in real time, including attempting to locate a matching event record. There are first and second capture databases for optimal real time performance of capturing the event records and triggering the real time processing. When a matching event record is located it updates an attendance database record with the full data,both recorded and calculated,for the activity marked by the start and end events. Subsequently, the server performs batch processing with the benefit of all event data and derived processed data for matching on/off events being available in the attendance database record. Notifications may be sent to employees if there is non-adherence to a rule, and responses are used as records for the employee database. There is optimum use of third party communication servers by scheduling notification messages in advance for pre-set times and cancelling them if applicable immediately before the pre-set times.

Description

"A Time and Attendance Processing System"

INTRODUCTION Field of the Invention

The invention relates to systems for capturing of time and attendance data at terminals, and processing of such data. Such systems may have hundreds or thousands of terminals at locations such as points of entry, particularly if the central server is host for multiple organisations. An example is a cloud-based service.

The processing which is carried out may be very intensive due to the large volume of incoming terminal data and the data processing may be very complex. The latter is increasingly the case due to the many and diverse parameters involved in payroll processing. For example, there may be different pay rates and tax and insurance computations for different days of the week, hours of the day, and grades of employment. In a typical prior art approach the incoming terminal data is saved to a database as a database record. Hence in a typical day for one employee there may be several database records created, one for each of activities such as arrival at work, going on a lunch break, coming back from the lunch break, and leaving work being examples. At a later time the central server runs a process to generate reports so that the data is useful for the employer. This involves very many database fetches and updates to locate the records and generate fresh ones for calculated data. Such processing can be very processor-intensive and may be error-prone due to not only the volume of data and complexity of the processing but also due to discrepancies such as terminal data indicating that a particular employee has checked out but not checked in. This may arise if there was a communications outage when the employee was checking in or if he or she erroneously operated the terminal upon arrival.

US2008/0114683 (Neveu et al) describes a remote time and attendance system with local clients, a local server, and wireless communication systems. US2005/0154920 (Tartaglia) describes an apparatus for biometric data collection, and these can be used to perform time and attendance functions. US2007/0096869 (Trohler) describes a work time recording method in which user data is recorded by a data recording client.

The invention is concerned with increasing the reliability, and/or speed, and/or and efficiency of time and attendance processing where the volume of records is high and the processing is complex. Another objective is to achieve improved versatility in use of local terminals as a wide variety of such devices is becoming available with ever improving biometric sensing.

SUMMARY OF THE INVENTION

According to the invention, time and attendance processing system comprising:

a plurality of terminals having employee verification capability,

at least one server, and means in the terminals and the server to communicate with each other via a wide area network;

wherein the terminals are each adapted to send in real time an event record in response to an event marking start or end of an employee activity; wherein the server is adapted to, upon receiving an event record:

perform initial processing of data in the event record in real time, create an attendance database record for this event if one does not exist already,

if an attendance database record exists already, open said record, populate the attendance database record with data from the received event record and with data values which have been calculated in said real time processing using the event record data, and

wherein the server is adapted to subsequently perform batch processing to generate reports using said data in the attendance database records..

In one embodiment, the terminals are adapted to send the event records with an event flag, an employee identifier, and a time stamp.

In one embodiment, the terminals are adapted to generate and send the event records in a universal format. In one embodiment, the initial processing includes checking received data against schedule data for the employee, and generating an anomaly alert if schedule data is not found or if a logically previous matching event has not occurred In one embodiment, the server is adapted to perform said initial processing including saving an incomplete attendance database record populated with received event and processed data, and subsequently completing said attendance database record upon receipt of an event record for the matching event. In one embodiment, the initial processing includes calculating a time difference between matching events if they are both received.

Preferably, the server is adapted to save incoming event records to a capture database which is separate from the attendance database. In one embodiment, said capture database is a first capture database, and the server is adapted to transfer event record data from said first capture database to a second capture database before performing said initial processing. In one embodiment, said transfer is performed by a looped service. In one embodiment, the looped service frequency is configurable. Preferably, the second capture database has code for triggering at least some of the initial processing upon insertion of the event record data into the second capture database. In one embodiment, in the looped service is threaded.

In one embodiment, the second database is grouped on customer, the server being adapted to receive event records from any of N terminals for each of M customers. In one embodiment, the server is adapted to automatically send, during said initial processing, a notification message to an employee upon occurrence of a condition and to save the notification and a corresponding response to a human resources database.

In one embodiment, the server is adapted to send said notification if there is a discrepancy between an event record time value and a schedule time value. In one embodiment, the server is adapted to direct transmission of the notification to a manager, and to automatically save a response from the manager in said human resources database.

In one embodiment, the server is adapted to send a management alert upon an anomaly condition including a condition of an event occurring without a logically previous matching event occurring. In one embodiment, the server is adapted to instruct an external communication system to send a notification at a pre-set time on the assumption that it will be required, and to cancel the instruction immediately before the pre-set time if it is not required. In one embodiment, the server is adapted to send said notification instruction via an API call. Preferably, the server is adapted to apply the pre-set time as a scheduled time for an event and to cancel the instruction in real time upon occurrence of the event before said pre-set scheduled time.

In one embodiment, the server is adapted to retrieve from a third party server address data for the employee.

In one embodiment, at least some terminals are adapted to perform initial processing using received data. In one embodiment, said terminals are adapted to store schedule variables or information per employee. In one embodiment, said terminals are adapted to automatically delete said information after a period of time, such as a work cycle of a day or week.

In another aspect, the invention provides a computer readable medium comprising software code adapted to perform the operations of a system as defined above in any embodiment when executing on a digital processor.

DETAILED DESCRIPTION OF THE INVENTION

Brief Description of the Drawings The invention will be more clearly understood from the following description of some embodiments thereof, given by way of example only with reference to the accompanying drawings in which :-

Fig. 1 is a combined block and flow diagram for a payroll system of the invention, in which the flow is for upload of a record indicating that an employee is on duty, including records for the server data processing in the flow of Fig. 1;

Figs. 2 to 8 are flow diagrams for each of seven other events at a point of entry terminal,

Figs. 9 to 11 are flow diagrams for downstream processing by the server processors; Fig. 12 is a diagram showing local processing at terminals; and Fig. 13 is a diagram illustrating automatic data gathering. Description of the Embodiments

Referring to Fig. 1, a point of entry terminal 1 records an event which is activated by an employee. At the hardware level there may be card, fingerprint or PIN verification, or any combination of these. There are in this embodiment eight events, labelled Fl - F8. The Fl event means that the employee has arrived on duty, and the terminal 1 uploads via the Internet 2 an event record with an Fl flag, the date, the time, and the employee ID. This record is made up of (Fl, datetime, employeeid).

There is a universal format to the event records, across multiple terminals in multiple organisations which upload to the server 3. The terminals may be of any of a range of types with different verification procedures such as biometric verification. There is therefore excellent versatility, as the server only needs to receive this format and no further configuration of the terminals is required.

Immediately the Fl record is received by the server 3 it writes the event record to an event record database, and then dynamically performs initial time and attendance processing (4(a)). The latter involves comparing the date and time values of the event record against the employee's scheduled start time to determine if there are discrepancies and makes basic decisions according to this. The server 3 then proceeds to locate a matching F2 record for this employee.

This dynamic processing also involves automatically transmitting (4(b)) a notification to the employee, which may include a query. If no schedule data is located the event record is flagged as an anomaly (4(c)) and a management alert is automatically generated.

If the matching event F2 record is found processing 5 is performed. This involves updating a current database record with the Fl and F2 details and calculations, and calculating the difference between the Fl and F2 record times. The server 3 then updates all fields of the time and attendance database record and saves them in step 7. This involves calculations which the system predicts will be required for reports.

In practice reception of the F2 record will typically occur several hours after reception of the Fl record.. Typically the F2 record is not found immediately and so the server 3 creates a new attendance database record with empty fields for the awaited F2 data. The server 3 saves the incomplete attendance database record in step 7. When the F2 data subsequently arrives processing is performed so that the remainder of the attendance database record is populated, not only with "raw" data but also data which is calculated in real time. This processing is shown as step 5 if the F2 record is located immediately, and as step 15 if Fig. 2 if subsequently received.

Fig. 1 shows examples of database records. The major differences are in the calculated fields, as these may be different due to different allowed adjustments. The invention however provides very efficient and robust processing by using matching events to complete an attendance database record.

The server 3 performs the dynamic processing in a very efficient manner, partly because it uses a single event records first capture database for immediately capturing the incoming event records from all terminals. In this database the event records are marked as un-processed. A Windows™ service loops to select all un-processed rows of this event records capture database. The loop frequency depends on the number of terminals, but can be set to any value between a few ms and several seconds. The service analyses each row in a threaded manner to insert the event record data into a second capture database, with tables grouped on customer. The server 3 has N configured organisations and each organisation has M terminals. There is one database, or one database table, for each customer grouping of M terminals.

Each of these second capture databases is programmed in SQL to automatically trigger the dynamic processing upon each insertion. This mechanism avoids any potential locks which might otherwise be caused by the dynamic processing, the latter is downstream from the first capture database and there is no interruption to the looped service.

Advantageously, the dynamic processing which is triggered by the second capture database does not only involve populating the attendance database with the raw event record data. In real time in the steps 4 and 5 (or Fig. 2) calculations are performed provide data which it is predicted will be required at a later time for reports. Examples are the adjustment and total discrepancy data items in the table of Fig. 1. These examples are from the attendance database. We have found that subsequent generation of a report is very much faster as a result. In tests, we have found that conventional algorithms take about 2s per employee per day for generating the calculations required for a schedule. For a week for a small organisation with 30 employees the total is over 300s. Such algorithms need to take this amount of time because of the need to retrieve the raw data from various locations in an attendance database and process it to generate calculated data which is then further processed to generate the required reports.

On the other hand, in the invention, such a report takes only about 5 seconds, only one sixtieth of the typical prior art time. This is because the server has distributed its processing over the full 24 hour period with real time dynamic processing, because of the structure of the attendance database with incomplete and complete records, because of use of the capture database as described, and by calculating data items in real time an only needing to retrieve them subsequently.

Moreover, integrity of the attendance data is ensured to a much greater extent than the prior art. This is because of the simple structure of the real time processing, using a single attendance database record for each matching pair of events, but also because of the notifications which are sent out n real time. In practice such notifications greatly reduce the number of major discrepancies arising from missing events such as an employee checking out without a corresponding checking-in event. |Even where this is not avoided in the system, a management alert is generated in real time and this can be used when generating a report to avoid excessive algorithm complexity.

Fig. 2 is the flow in response to an F2 event, indicating that the employee has gone off duty. Initial processing 10 is carried out if schedule data is found, or an alert is generated in step 1 1 if not. Also the flow 10 may result in generation 12 of an alert, depending on employment rules.

If a matching attendance database record with Fl data is found processing 15 takes place using the benefit of the full Fl and F2 data, enabling the attendance database record to be saved. However, if the matching Fl record is not found a record with some empty fields is generated in step 16. Again sample records are shown in Fig. 2. In step 16 the server generates a partial attendance database record if the Fl event has not occurred. As noted above, this may arise due to error on the part of the employee or the system's communications link.

In this case it is likely that the Fl record will be immediately located because the Fl event is chronologically before the F2 event. An advantageous aspect of the server operation is that, upon receipt of an event record, it performs initial processing to fully or partially complete an attendance database record. If partial, it will automatically complete the attendance database record upon subsequent arrival of the matching event record. Referring to Fig. 3 the processing 20 for events F3 and F4 is illustrated, as follows:

21, save the F3 record to the first capture database followed by insertion in to the second capture database;

22, check for corresponding schedule information for this employee and in step 23 flag an anomaly if this is not found;

24, search for the matching event record F4;

25, if F4 event record located, update the attendance database record with updated fields;

26, if not found, create a new attendance database record with empty fields for updating when the F4 event record is received subsequently; and

27, commit the attendance database record.

Event F3 indicates that the employee is off the premises. Again, there is initial processing, depending on whether there is a matching F4 event (on-premises). Fig. 4 shows the flow for the matching event F4. The server processing, 40, mirrors that for F3. Even though the events F3 and F4 are quite different from the events Fl and F2 the processing by the server 3 is on the same basis s for Fl and F2, initial processing followed by completion in response to arrival of the matching event record.

The following table illustrates the recorded times for the server 3 receiving an event record and performing the real time processing as described above for six examples. The first column is the test number, the second is the on-duty event Fl or F3 of F5 or F7 and the third column is the matching off-duty event F2, F4, F6, or F8. Table 1

On average therefore there is an average time of 544 ms per each matching pair of events. If there are three matching pairs of events for each employee per day there is a total time per employee of about 1.6 s per day, and per week of 8.1s. When subsequently generating a report it is simply a matter of retrieving the calculated data values from the attendance database. We have found that this takes in the range of only 200 to 300 ms. The longer time required for the first test is accounted for by the fact that SQL code is not immediately present in RAM, but is for the later tests.

Event F5 indicates that the employee is on break, and the processing (50) depends on F6 (off break) event record arrival. The flows are shown in Figs. 5 and 6. In these flows there is also a search for attendance database records with events F7 and F8 (on smoke break, off smoke break). The processing mechanism of the server 3 is similar to that described above for Fl to F4 processing, with the exception that there is an additional search 51 performed for events F7 and F8 because these events are related. Fig. 6 shows the corresponding processing, 60, upon receipt of an F6 event record.

Fig. 7 shows the terminal 1 uploading an F7 event record and the consequent server 3 processing 70. This mirrors that of the processing 50. Fig. 8 shows the terminal uploading an F8 (Off Smoke Break) event record and the consequent server processing 80. Again, there is initial processing (81) if the matching event record (F8) is located and creation of a partial attendance database record (82) if not. It will be appreciated that the events Fl - F8 are by way of example. There may be additional events depending on the nature of the employment and the rules. In most cases, however, there will be pairs of matching events, one for starting and one for ending an activity. By generating incomplete attendance database records with empty fields there may be very fast and efficient matching in real time when the matching event occurs, at all times with maximum processing being performed in real time.

An example of a report is a payroll report, uses the results from the processes described above (F1-F8) to generate a payroll result set. Since records have already been matched, assigned to correct schedules, flagged as anomalies, taken account of leniency variables, had durations calculated, identified as being during breaks etc., this drastically reduces the workload placed on the server to generate the payroll report.

Fig. 9 shows the batch processing 90 which takes place when all events have occurred. Again these will depend on the nature of the employment rules, which are not the subject of the invention.

Fig. 10 shows the communication aspects for alert notifications. Fig. 2, step 12 shows an email/SMS alert being sent. In Fig. 10 the stored procedure 12 initiates the process if the employee was late, left early or took too long on lunch and was to be contacted by SMS.

The first flow 100 shows the stored procedure getting the respective employee's telephone number and sending the SMS via some third party method (either a com object or a web service to initiate methods of the SMS gateway). The com object or Web service returns a unique SMS ID for the SMS. These details are recorded in a shared SMS database and in the customer's SMS table.

The next flow, 110, shows what happens when the third party SMS gateway replies with a delivery status for an SMS which was sent. The third party gateway knows to contact a specific public http page belonging to the service. This page analyses the query string of the third party gateway response and records the delivery status against the correct SMS message in both the shared SMS database and the customer's SMS table. The flow 120 of Fig. 10 shows what happens when an employee replies to an SMS which was sent in a step such as the step 12. When the employee replies to the text message, it is received by the third party SMS gateway and the response is forwarded to a specific public http page belonging to the service. This page records the employee's reason for being late, leaving early or taking too long on lunch etc. (not limited to being late, leaving early or taking too long on lunch).

An advantageous aspect of the server notification operations is that it automatically records consistent HR notes against employees' timekeeping records. In this way, a manager does not need to be involved in the process for finding out reasons why an employee was late. The system asks the employee via SMS for a reason and the employee's explanation (SMS reply) is recorded as a HR note. This note can be referenced at any time for payroll or employee appraisals. The processes 100, 110, and 120 eliminate a manager from having to monitor an employee's time records, deduce if they were late, left early or took too long on a break, physically ask an employee for a reason and then physically record that reason. The server 3 handles this process automatically with the co-operation of the employee.

Any reply which is received from an employee is recorded and a copy is automatically sent to a manager address. The manager may respond if he or she wishes so that there is a dialogue. Again, there is a complete record of this dialogue, available at a later time for HR purposes. Fig. 11 shows examples of the notifications and corresponding database tables.

Referring to Fig. 12 in a flow 150 the terminals also have the ability to calculate data for payroll reports if required. The terminal can receive a copy of and store 30 days of scheduling information (work at 2012-01-01 09:00:00 -2012-01-01 18:00:00, allowed 1 hour break etc.) for each employee. The terminal can also store schedule information or variables for each employee such as 'discrepancy leniency'. This information is sent from the server 3 to the terminals 1. As each employee finishes a work shift (F2) and the server receives all the calculated results, the scheduling information for that shift is no longer required and deleted. Fig. 13 shows a sequence 160 of steps for Fl, in which the terminal is used to calculate results for payroll. A similar flow is implemented where the event is F2, in which the relevant F2 details are updated. Importantly, the calculated results are uploaded to the server with a relevant flag. This arrangement achieves very effective distributed processing, further enhancing server performance. Referring again to the notification processing, checking to send SMS/Email/Push notifications at the most common start and finish times (for example 9am, 9.30am, 5pm, 5:30pm, 6pm) puts a great strain on the server 3. Sending real-time notifications to all employees that are late or leave early is not possible. The server 3 can hold data for over 100,000 employees. If 1% are late, sending 1000 messages at 9am is a difficult task.

To send an SMS, the server 3 uses a HTTP or Com object call to an SMS Gateway. The average time spent to send an SMS using a third party API is 2 seconds. A single message could only ever be sent in real time with complex threading and multiple queues with multiple windows services are to be implemented.

To overcome this limitation the server 3 schedules a message for every employee by presuming that they are late. The third party API has scheduling and cancel functions. As soon as a schedule is entered for an employee, the server 3 immediately schedules a notification on the assumption that one will be required. This shares the load of sending the notification in that random moment, rather than at 9am. The third party API will take care of sending the notification at the correct time. If the employee is early, the server 3 cancels the scheduled notification at that random point in time (random as in the moment an employee clocks-on, which is totally unpredictable) - this is possible as all records are delivered to our server in real-time.

The same methods are used for ensuring that people use the Off Duty button. At the time of scheduling, the server adds 2 hours to their schedule finish time and schedules a notification to be sent requesting them to clock off. If they clock off, the notification is cancelled.

Our biggest performance increase is regarding lunch break notifications. If an employee has 30 minutes break, it is not possible to review every employee that is on a break, and check their On Break time against their "On Break time plus 30 minutes" and compare this value to the current system time. I.e. An employee starts their break at 12.03 with a 30 minute break duration. The server would check their On Break time at 12.03 against the time of 12.33 every few milliseconds to conclude if a notification should be sent if that employee does not clock an Off Break before 12.33. Once again, we presume that an employee will be late. At 12.03, when the employee in question clocks an On Break, the server 3 immediately schedules a notification for 12.33 with the 3rd party provider requesting the employee to finish their break.

If the employee presses an Off Break before 12.33, the server 3 simply cancels the notification with the third party provider.

Using this example, if the server were to deploy a check in real time without scheduling, the check would run over 10,000 times for this single employee in the space of 30 minutes. This is very resource-intensive. With the above method, it does two rounds, one to schedule the SMS notification, and one to cancel. This achieves a huge performance gain as well as distributing any computations based on the random real-time event of an employee clocking off a break. It will be appreciated that the invention allows use of any of a wide range of available terminals, with different employee identification technologies such as biometrics. This is because the server processes event sin a universal manner, by performing initial processing and searching for a matching event record. Also, there is no need for the providers of the server 3 to have access to source code of the terminals. This allows excellent versatility.

It will also be appreciated that the invention achieves much faster response times for generation of reports. Also, because of the on going dynamic nature of much of the processing there is real time communication with manager and employees helping to reduce discrepancies and automatically record HR data with little or no human manager time required.

The invention is not limited to the embodiments described but may be varied in construction and detail.

Claims

A time and attendance processing system (1, 3) comprising:

a plurality of terminals (1) having employee verification capability,

at least one server (3), and means in the terminals (1) and the server (3) to communicate with each other via a wide area network (2);

wherein the terminals are each adapted to send in real time an event (F1-F8) record in response to an event marking start or end of an employee activity;

wherein the server (3) is adapted to, upon receiving an event record:

perform initial processing (4(a)) of data in the event record in real time, create an attendance database record (6) for this event if one does not exist already,

if an attendance database record exists already, open (7) said record, populate (7) the attendance database record with data from the received event record and with data values which have been calculated in said real time processing using the event record data, and

A time and attendance processing system as claimed in claim 1, wherein the terminals (1) are adapted to send the event records with an event flag, an employee identifier, and a time stamp.

A time and attendance processing system as claimed in claims 1 or 2, wherein the terminals (1) are adapted to generate and send the event records in a universal format.

A time and attendance processing system as claimed in any preceding claim, wherein the initial processing (4(a)) includes checking received data against schedule data for the employee, and generating (4(c)) an anomaly alert if schedule data is not found or if a logically previous matching event has not occurred

A time and attendance processing system as claimed in any preceding claim, wherein the server is adapted to perform said initial processing including saving (6) an incomplete attendance database record populated with received event and processed data, and subsequently completing (7) said attendance database record upon receipt of an event record for the matching event.

6. A time and attendance processing system as claimed in claim 5, wherein the initial processing (4(a)) includes calculating a time difference between matching events if they are both received.

7. A time and attendance processing system as claimed in any preceding claim, wherein the server is adapted to save incoming event records to a capture database which is separate from the attendance database.

8. A time and attendance processing system as claimed in claim 7, wherein said capture database is a first capture database, and the server is adapted to transfer event record data from said first capture database to a second capture database before performing said initial processing.

9. A time and attendance processing system as claimed in claim 8, wherein said transfer is performed by a looped service.

10. A time and attendance processing system as claimed in claim 9, wherein the looped service frequency is configurable.

11. A time and attendance processing system as claimed in any of claims 8 to 10, wherein the second capture database has code for triggering at least some of the initial processing upon insertion of the event record data into the second capture database.

12. A time and attendance processing system as claimed in any of claims 9 to 11, wherein the looped service is threaded.

13. A time and attendance processing system as claimed in any of claims 9 to 12, wherein the second database is grouped on customer, the server being adapted to receive event records from any of N terminals for each of M customers.

14. A time and attendance processing system as claimed in any preceding claim, wherein the server is adapted to automatically send (4(b)), during said initial processing, a notification message to an employee upon occurrence of a condition and to save the notification and a corresponding response to a human resources database.

15. A time and attendance processing system as claimed in claim 14, wherein the server (3) is adapted to send (4(b)) said notification if there is a discrepancy between an event record time value and a schedule time value.

16. A time and attendance processing system as claimed in claims 14 or 15, wherein the server is adapted to direct transmission of the notification to a manager, and to automatically save a response from the manager in said human resources database.

17. A time and attendance processing system as claimed in any preceding claim, wherein the server is adapted to send (4(c)) a management alert upon an anomaly condition including a condition of an event occurring without a logically previous matching event occurring.

18. A time and attendance processing system as claimed in any of claims 14 to 17, wherein the server is adapted to instruct an external communication system to send a notification at a pre-set time on the assumption that it will be required, and to cancel the instruction immediately before the pre-set time if it is not required.

19. A time and attendance processing system as claimed in claim 18, wherein the server is adapted to send said notification instruction via an API call.

20. A time and attendance processing system as claimed in claim 19, wherein the server is adapted to apply the pre-set time as a scheduled time for an event and to cancel the instruction in real time upon occurrence of the event before said pre-set scheduled time.

21. A time and attendance processing system as claimed in any preceding claim, wherein the server (3) is adapted to retrieve from a third party server address data for the employee.

22. A time and attendance processing system as claimed in any preceding claim, wherein at least some terminals (1) are adapted to perform initial processing using received data.

23. A time and attendance processing system as claimed in claim 22, wherein said terminals are adapted to store schedule variables or information per employee.

24. A time and attendance processing system as claimed in claim 23, wherein said terminals (1) are adapted to automatically delete said information after a period of time, such as a work cycle of a day or week.

25. A computer readable medium comprising software code adapted to perform the operations of a system as claimed in any preceding claim when executing on a digital processor.