7. Discussion

The system described here represents a minimum system that would fulfil the most pressing of the user group’s needs, namely assistance in dealing with locks and alarms, and assistance with recall for report writing. In particular it will satisfy the following user requirements:

• Hands-free retrieval of access codes for doors and alarm panels, plus help with the location of alarm panels.
• Hands-free recording of events, both while dealing with incidents and generally.
• Post-event browsing of event recordings, to assist with recalling details of earlier incidents for report writing (by reinstating the context in which the memory was stored).

A specific advantage for the University of Sussex’s security officers is the device’s log of locations entered. This is effectively a log of the route taken and will replace the unpopular clocking device currently carried by the security officers.

There is a great potential for adding functionality, both to enhance the system and to increase the potential user base. One potential enhancement to the system at Brighton University relates to their door access system. Most of the main doors to and within buildings are computer-controlled. When a person wishes to use a locked door (s)he uses a plastic card (with a magnetic stripe) to request access. This card is personal to that person. If the computer accepts the card is valid then it sends a signal to the door mechanism to unlock the door. It would be possible for the device to offer to unlock the door without being asked. The security officer could simply press the ‘help-me-out’ button to accept. Assuming the device has 2-way communication with the base computer, if the button is pressed then the device could send a request to the door control system to unlock the door.

A more general function that should eventually be practicable is that of face recognition. It is currently proposed that the device recognises that a conversation is in progress by identifying the (relatively static) anonymous shape of a human face in its visual field. Ultimately it is possible that the device will go on to identify the face from a database of students, tutors and other valid building users. Thus, on stopping someone to check their reasons for being in a particular location, the device could deliver the person’s name and status (eg: "John Smith, student until July 1997").

The role of the security services in society has been questioned in recent years by a variety of civil liberties organisations. The advent of CCTV in particular has caused much debate. One organisation, Privacy International (1998), campaigns for legal restrictions on its use. They argue that the proponents of CCTV do so on unreliable evidence, such as a 90% reduction in car crime for example. Privacy International point to self-interest in the production of such statistics, such as ignoring the displacement of crime to other areas, and statistical irregularities. Without positive effects they see many dangers of CCTV use. In particular, they say, CCTV may undermine existing democratic systems, giving no legal protection for those whose image is captured. This allows, for example, CCTV operators to target people they may be prejudiced against. Privacy International specifically call for the "immediate restriction" of:

• Computerised face recognition systems that have the capacity to automatically compare faces captured on CCTV with a database of facial images"
• "Infra-red systems able to detect activity in the darkness"
• "Miniature and micro-engineered devices designed for covert surveillance"

Such concerns have implications for this project. The security officers currently place a high reliance on their existing CCTV systems (the hospital has 86 cameras) as a low-cost means of patrolling large areas and as a means to collecting evidence. The event recording aspect of the proposed device extends the CCTV concept into new areas and will, undoubtedly, accentuate existing concerns. Those whose image and voice will be captured are also, in a sense, users of the device. It may therefore be necessary to address these concerns should the device be commercially marketed.

The next steps in developing the device are suggested below. Note that each step is intended to be iterative, and may thus be attempted several times.

1. Produce a lo-fi mock-up of the device and test it with the users for size and weight
2. Produce a lo-fi mock-up of the audio interface and test it with the users (or possibly first with volunteers who have more free time than the users)
3. Produce a hi-fi mock-up of the device (such as looking like the finished product, but with wires to a portable computer)
4. Write a more advanced prototype of the software that can load information from the prototype device
5. Extensively test the combination of hi-fi prototypes with the users
6. Build several ‘finished products’ (apparently finished, but using more expensive methods than in the final saleable product, such as building manually rather than mass production). These would be given an extensive test by one or more of the users.