AU2007240178A1 - Document processing - Google Patents

Description

Australian Patents Act 1990 - Regulation 3.2 ORIGINAL COMPLETE SPECIFICATION STANDARD PATENT Invention Title Document processing The following statement is a full description of this invention, including the best method of performing it known to me/us: P/00/0l C I1 l DOCUMENT PROCESSING Field of the Invention The present invention relates to a method and apparatus for use in document processing and in particular for determining whether document processing can be performed based on user 5 privileges. Description of the Background Art The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as an acknowledgment or admission or any form of suggestion that the prior publication (or information derived from o it) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates. Multifunction print devices (MFDs) are devices that integrate a number of hard-copy document handling functions, such as facsimile transceiver, scanner, copier and printer, in a single device. MFDs are often integrated into a computer network in the modem office .5 environment allowing users to access MFD functions via personal computers coupled to the computer network, as well as via local inputs such as a touch-sensitive panel, or the like. The use of MFDs can be costly due to the amount of resources used to perform various MFD functions, such as printing. This issue is exacerbated in an office environment, where easy access to MFDs can result in high volume usage. 20 In such cases, restricting or otherwise controlling the access to selected costly functions on the MFD, such as colour printing, can become important. Such access control generally involves two connected steps, authentication of the user to allow the identity of the user to be established, and the second being establishing privileges associated with the identified user. These privileges indicate the right of the user to access a particular MFD resource or function 25 and can therefore be used to limit access to MFD functions.

-2 In some circumstances it can be advantageous for a user to be temporarily granted privileges they don't normally have. For example, in an environment where users aren't normally allowed to print in colour due to the higher price of colour ink/toner, on certain occasions a user may need to print a colour report, in which case they generally have to ask someone with 5 privileges to print in colour to perform the printing on their behalf, or seek to gain privileges to print in colour temporarily. A previous solution to MFD access control involved the use of user profiles, which contain privilege information, stored at the MFD. Users authenticate themselves, at which point their user profile, and hence user privileges, are retrieved. Granting temporary privileges to a user 0 involves changing their user profile, generally requiring multiple updates, once to grant the privilege and then once to revoke the privilege. This requires substantial time and effort, and is error prone. Another disadvantage is that the profile must be stored and possibly changed at each MFD. Another solution is to store the user profiles remotely to the MFD, for example on a network 5 server. This allows the same profile to be used for multiple MFDs, but still requires that the profile is modified each time to grant and revoke the privilege. In a large firm, access control and other aspects of security are generally handled by separate administrators and as a result, modifying the profile is still difficult and time-consuming. A simple solution is for the manager to lend the employee their authentication information so 20 that the employee may use the device on behalf of the manager. This is disadvantageous as it violates the security model, and does not allow the actions performed on the MFD to be accurately traced back to the employee. This is because the manager's details, such as the manager's username, will be tracked in the MFD usage log instead of the employee's. Reduced flexibility of traditional access control often directly opposes the traditional 25 approach to using document handling/processing devices. Administrators and managers wish to restrict access to the devices for the purposes of security accounting, whilst users expect to be able to use MFDs with minimum hindrance. A flexible yet secure approach to access control is therefore desirable.

-3 Summary of the Present Invention It is an object of the present invention to substantially overcome, or at least ameliorate, one or more disadvantages of existing arrangements. In a first broad form the present invention provides a method for use in processing a 5 document, the method including, in a processing system: a) determining a first set of privileges using authentication information indicative of a user identity; b) determining a second set of privileges using authorisation information; and, c) determining document processing that can be performed at least partially in 0 accordance with the first and second set of privileges. In a second broad form the present invention provides apparatus for use in processing a document, the apparatus including a processing system for: a) determining a first set of privileges using authentication information indicative of a user identity; 5 b) determining a second set of privileges using authorisation information; and, c) determining document processing that can be performed at least partially in accordance with the first and second set of privileges. In a third broad form the present invention provides a computer program product for use in processing a document, the computer program product including computer executable code 20 which when executed on a suitable processing system causes the processing system to: a) determine a first set of privileges using authentication information indicative of a user identity; b) determine a second set of privileges using authorisation information; and, c) determine document processing that can be performed at least partially in accordance 25 with the first and second set of privileges. Brief Description of the Drawings An example of the present invention will now be described with reference to the accompanying drawings, in which: -4 Figure 1 is a schematic diagram of an example of a networked environment containing a number of MFDs; Figure 2 is a schematic diagram of an example of an MFD; Figure 3 is a schematic diagram of an example of a computer system; 5 Figure 4 is a flow chart of an example of a process for use in document processing based on user privileges; Figures 5A and 5B are a flow chart of a second example of a process for use in document processing based on user privileges; Figure 6 is a flow chart of a first example use of a document processing process; 0 Figure 7A is a schematic representation of an example of a user interface for providing authentication information; Figure 7B is a schematic representation of an example of a user interface displaying privileges granted to a user; Figure 8 is a flow chart of a second example use of a document processing process in which 5 multiple authorisation tokens are presented by the user; Figure 9 is a flow chart of a third example use of a document processing process in which a user selects a task to be performed prior to presenting an authorisation token; Figure 10A is a schematic representation of an example of a user interface for indicating required authorisation tokens; 20 Figure 10 B is a schematic representation of an example of a user interface for indicating authorisation token validity; Figure 11 is a flow chart of a fourth specific example use of a document processing process in which privileges granted to a user are made to persist permanently; Figure 12 is a flow chart of a fifth specific example use of a document processing process in 25 which privileges are associated with an authorisation token; and, Figure 13 is a schematic representation of an example of tables used for tracking document processing operations. Detailed Description Including Best Mode An example of a system for use in performing document processing, such as document 30 scanning, printing, copying or faxing will now be described with respect to Figure 1.

-5 In particular, the apparatus includes a number of Multi-Function Devices (MFDs) 100, coupled to a number of computers 120, and optionally a number of servers 130, via a communications network 110. The servers may also be coupled to one or more databases 140, as shown. 5 In use, the MFDs 100 are used to perform various document processing functions, such as printing, scanning, copying, or faxing of documents, or the like. As part of this process, the computers 120 may be used to provide documents to the MFDs 100, for example in the case of printing applications, or may be used to display job results, for example following scanning of the documents by the MFDs 100. 0 Similarly, the servers 130 may be used to provide or receive documents used in jobs, as well as to provide additional network based activities, such as user authentication, document storage, file and print management and personal contacts management, and this may require interaction with data in the database 140. It will therefore be appreciated that a wide range of network architectures are encompassed 5 by the system and the configuration shown is for the purpose of example only. Thus, for example, the communications network may be any suitable communications network, but is typically a Local Area Network (LAN) 110 such as an intranet, although may also include a Wide Area Network, the Internet, or the like. Furthermore, any number of MFDs 100, computers 120, or servers 130 may be used, and the number shown is for the 20 purpose of illustration only. An example of one of the MFDs 100 is shown in more detail in Figure 2. In this example, the MFD includes a scanner 200, a printer 205, a fax 210 unit, an optional dedicated copier 215, an Input/Output (1/0) controller 220, a multi-function controller 225, and a user interface controller 230, coupled together via a bus 235, as shown. 25 The user interface controller 225 is typically coupled to one or more user interface devices, such as a touch screen 240 and keypad 245, to allow a user to view information provided by the MFD 100 and provide appropriate input commands. A recognition device 250 may also -6 be provided for obtaining information for identifying users. This may include for example a biometric scanning device, or a swipe card or RFID (Radio Frequency Identification) tag reader for reading information from a suitable swipe card or RFID tag. In use, the I/O controller 220 operates to handle interaction with external devices, such as the 5 network 110, whilst the multi-function controller 225 operates to control the scanner 200, printer 205, fax 210 and copier 215, to allow desired jobs to be performed. It will therefore be appreciated that the controllers are typically implemented as software executed by a suitable processor, which is operating under control of appropriate software applications stored in a store (not shown). 0 It will be appreciated that the MFD operation is typically controlled using software executed by an appropriate processor, such as the multi-function controller, although any suitable control mechanism may be used. In one example, selectively performing document processing as described in more detail below may be performed through the use of a suitable module loaded into the processor from 5 memory, and this is typically implemented by the multifunction controller 225. This may be achieved in any one of a number of manners, but in one example may be achieved using a Java module that activates a graphical user interface (GUI) on the touch screen 240, and interacts with the computer 120 and/or the servers 130 as required. This allows the MFD 100 to be display information and options relating to the document processing, as well as to allow 20 the user to provide input commands to control the document processing process. In addition to this, this allows the MFD to communicate with the computers 120, servers 130 and databases 140 as required, as will be described in more detail below. An example of a general-purpose computer 120 is shown in Figure 3. The computer system 300 is formed by a computer module 301, input devices such as a 25 keyboard 302 and mouse 303, and output devices including a printer 315, a display device 314 and loudspeakers 317. The computer module 301 typically includes at least one processor unit 305, and a memory unit 306, for example formed from semiconductor random access memory (RAM) and read -7 only memory (ROM). The module 301 also includes an number of input/output (1/0) interfaces including an audio-video interface 307 that couples to the video display 314 and loudspeakers 317, and an I/O interface 313 for the keyboard 302 and mouse 303 and optionally a joystick (not illustrated). An 1/0 interface 308, such as a network interface card 5 (NIC) is also typically used for connecting to the computer to the network 1 10. A storage device 309 is provided and typically includes a hard disk drive 310 and a floppy disk drive 311. A magnetic tape drive (not illustrated) may also be used. A CD-ROM drive 312 is typically provided as a non-volatile source of data. The components 305 to 313 of the computer module 301, typically communicate via an 0 interconnected bus 304 and in a manner that results in a conventional mode of operation of the computer system 300 known to those in the relevant art. Examples of computers on which the described arrangements can be practised include IBM-computer's and compatibles, Sun Sparc stations or the like. The performance of document processing, such as printing, is typically implemented using 5 software, such as one or more application programs executing within the computer system 300. Typically, the application activates a GUI on the video display 314 of the computer system 300 which displays documents to be printed, or scanned or copied documents. In particular, the methods and processes are affected by instructions in the software that are carried out by the computer. The instructions may be formed as one or more code modules, 20 each for performing one or more particular tasks or document processing functions. Typically the execution of the instructions may require a number of different application programs to interact, and may also require the presence of a suitable driver that is configured to operate with a specific device or MFD. The software may be stored in a computer readable medium, and loaded into the computer, 25 from the computer readable medium, to allow execution. A computer readable medium having such software or computer program recorded on it is a computer program product. The use of the computer program product in the computer preferably affects an advantageous apparatus for distributed printing, scanning or copying.

The term "computer readable medium" as used herein refers to any storage or transmission medium that participates in providing instructions and/or data to the computer system 300 for execution and/or processing. Examples of storage media include floppy disks, magnetic tape, CD-ROM, a hard disk drive, a ROM or integrated circuit, a magneto-optical disk, or a 5 computer readable card such as a PCMCIA card and the like, whether or not such devices are internal or external to the computer module 301. Examples of transmission media include radio or infra-red transmission channels as well as a network connection to another computer or networked device, and the Internet or Intranets including e-mail transmissions and information recorded on Websites and the like. 0 An example of a method for use in document processing will now be described with reference to Figure 4. In this example, at step 400, a processing system, such as an MFD 100, a computer system 120 or a server 130, determines a first set of privileges using authentication information indicative of a user identity. 5 The first set of privileges is typically indicative of one or more available document processing functions that the user is allowed to perform, and this therefore represents access rights to document processing functions that can be performed at least in part using the MFDs 100. The first set of privileges may be determined in any one of a number of manners, but 20 typically this process involves having a user provide authentication information to an MFD 100, or computer system 120. The authentication information can be used by the processing system to determine a user identity associated with the user, which can in turn be used to access a relevant first set of privileges stored either on the MFD 100, the computer system 120, the server 130 or in the database 140. 25 The authentication information may be provided using any suitable techniques, such as by having the user supply a username and password or biometric data via a suitable input, or by having the user present an authentication card to a card reader, depending on the preferred implementation.

-9 At step 410, a second set of privileges are determined using authorisation information. The second set of privileges is also typically indicative of one or more available document processing functions, and these represent additional access rights that can be granted to a user to allow additional document processing functions, beyond those specified in the first set of 5 privileges, to be performed. Again, this may be achieved in any one of a number of manners, but typically involves having a user provide authorisation information to an MFD 100, or computer system 120, using a physical authorisation token such as authorisation card. In this example, the authorisation information can be determined based on data received from a token sensor. This 0 allows the processing system to access a relevant second set of privileges that can be stored on the MFD 100, the computer system 120, the server 130 or in database 140 or the card itself. At step 420 the processing system determines document processing that can be performed at least partially in accordance with the first and second set of privileges. 5 Thus, this process effectively examines whether the access rights granted to the user by the first and second set of privileges are sufficient to allow required document processing functions to be performed. This may be achieved in any suitable manner. In one example, this is performed after a user has selected a document processing function by having the processing system compare the 20 user selected document processing function to available document processing functions to determine if the user selected document processing function can be performed. Once this is completed the processing system can selectively cause the document processing to be performed in response to the results of the comparison. Alternatively, this can be performed before the user has selected a document processing 25 function by having the processing system determine available document processing functions and then cause an indication of these to be presented to a user to allow user selection of an available document processing function, which can then be performed.

-10 The above described process therefore provides a mechanism to supplement access rights granted to users by a first set of privileges with additional access rights indicated in a second set of privileges. This can be used to provide temporary additional access rights to a user, without requiring modification of the first set of privileges associated with the user. Thus, 5 additional access can be granted on a one off, or timed basis, providing a mechanism for allowing the user to perform additional document processing functions when required, whilst the user's normal access rights are maintained, so that the user's existing access rights persist when the additional document processing functions are no longer required. It will be appreciated from the above, that the processing system may form part of any one or 0 more of the MFD 100, the computer system 120 or one of the servers 130, depending on the preferred implementation. Thus, this process could be performed entirely within an MFD 100, without requiring the MFD 100 to be connected to the network or any other device. Alternatively however, performance of the above described processes can be distributed amongst the devices on the network 110. Thus, for example, the authentication and/or 5 authorisation information could be provided via an MFD 100, with this information being transferred to the server 130 to allow the privileges to be determined. The privileges can then be used by the MFD 100 or the server 130, to determine whether document processing should be performed, with this determination being used to control the document processing performed by the MFD 100. A specific example of this will now be described in more detail 20 with respect to Figures 5A and 5B. In this example, at step 500, a user provides authentication information to an MFD 100, for example by supplying a username and password to the MFD 100. At step 505, the MFD 100 transfers the authentication information to the server 130, allowing the server to authenticate the user at step 510. 25 If it is determined that the user is not authenticated at step 515, then it is determined that document processing cannot be performed and an indication of this is usually provided to the MFD 100 at step 520, so that document processing can be halted.

- 11 In the event that the user is authenticated successfully at step 515, then the server 130 uses a user identity, such as the username, to retrieve the first set of privileges associated with the user. This typically involves accessing sets of privileges that are stored together with the user identity of the corresponding user in the database 140. However, in the event that privileges 5 have not been previously defined for the user, then the first set of privileges may be based on a default set of privileges. The first set of privileges can then be transferred to the MFD 100 at step 530, where they are typically temporarily stored in a memory associated with the multi-function controller 225 as current user privileges. This allows the multi-function controller 225 to determine available 0 document processing functions from the current user privileges, and then display a list of these at step 535 using the touch screen 240. In this instance, unavailable functions may also be identified, for example, by displaying unavailable functions partially obscured or in faded text. This allows the user to assess whether required document processing functions are available at step 540. 5 If required document processing functions are available, then at step 545, the required document processing can be performed, with the process then terminating, and a usage log being optionally updated as will be described in more detail below. However, if required document processing functions are not available, then at step 550 the user presents an authorisation token to the MFD 100, for example by providing this to the 20 recognition device 250. Thus, for example, if the user wants to print or copy a document in colour and the first set of privileges only allow printing in black and white, then the user can present a "print in colour" authorisation token. At step 555, the MFD 100 determines authorisation information, such as a token identifier (token ID) and transfers this to the server 130. At step 560 the server 130 uses the token ID 25 to access a second set of privileges stored in the database 140, or on the MFD 100 or the token itself. This typically involves accessing sets of privileges for each available authorisation token that are stored together with associated token IDs in the database 140. During this process, the server 130 may also perform one or more checks of the authorisation - 12 information, for example to confirm that the authorisation information is valid, has not expired, or the like. At step 565, the second set of privileges is transferred to the MFD 100, allowing the MFD to form a current set of user privileges based on a combination of the first and second sets of 5 privileges at step 570. The current set of user privileges are typically stored in memory associated with the multi-function controller 225, as will be appreciated by persons skilled in the art. At step 575, the MFD 100 displays an updated list of available document processing functions based on the current user privileges. Assuming the updated list includes the 0 document processing functions required by the user, then the user can select the required document processing function. The MFD 100 therefore determines that the document processing can proceed, and performs the required document processing functions at step 580. Following successful processing of the document, the process is finalised, which may involve 5 purging the current user privileges from the MFD 100 memory. This is performed so that the next user will need to authenticate themselves in order to perform any document processing. This also means that should the same user attempt to perform document processing, they will also have to re-authenticate themselves, causing the first set of privileges to be retrieved and used as the current user privileges. This effectively revokes their access to the second set of 20 privileges, so that their access rights remain at their original level, and not the higher level associated with the authorisation token. Revocation of high privileges can however, be performed at any appropriate time, such as at the end of a user login session, or the like. At this time, a usage log may also be updated to reflect the document processing performed by the user, as well as the use of any authorisation token in performing the document 25 processing. The usage log typically includes usage information indicative of performed document processing, an identity of the user and any authorisation information, such as an indication of a token ID of an authorisation token used to perform the document processing.

- 13 It will be appreciated that a number of variations and usage scenarios can be implemented as part of the above described process, as will be described in more detail below. A first example use, in which employees within an organisation are authorised to perform certain functions using an MFD, will now be described with reference to Figure 6. 5 For the purpose of this example, all employees have a personal profile containing: e An email address e A phone number e An MFD privileges set The MFD privilege set includes privileges granted to the user, which govern what functions 0 of an MFD a user is allowed to use. For example, for a regular employee, these privileges may be: e Scanning A4 * Printing black/white, A4 e Copying black/white, A4 5 For a manager, the set of MFD privileges may be: e Scanning, any paper size e Printing black/white or colour, any paper size e Copying black/white or colour, any paper size These privileges are generally set by an administrator, and may be stored locally on each 20 MFD 100, or centrally, either on the server 130 or in the database 140. The privileges are generally governed by company policy on MFD usage. Privileges may also have defaults, to cater for cases where a privilege is not explicitly stated for each user. Privileges set explicitly for users may override the defaults. In the example scenario, all employees are allowed to print in black and white only. In 25 exceptional cases, employees may need to print a document in colour. In such cases, they request to be allowed to print in colour temporarily from their manager.

-14 In this example, an authorising party such as the manager of a department, keeps an authorisation token representing authorisation information that is associated with a second set of privileges, which in this example includes the right to perform colour printing. The authorisation token is a physical token, such as a swipe card or smart card so that when a user 5 needs to perform functions that are not permitted by their current privileges set, they can acquire the authorisation token from the manager. This allows their current privileges to be temporarily raised to allow colour printing to be performed. After the function is performed, the user's privileges can be returned to normal, with the user returning the token to the manager. As the token is not associated with any particular user 0 profile it can be used by anybody who possesses it, and can therefore be reused by other users in the event that they need to perform colour printing. The process commences when the user approaches the MFD 100 at step 600 and provides authentication information at step 601. The authentication information may be a username and password pair or a physical token such as a swipe card or fingerprint and is used to 5 identify the user during any further activity at the MFD. It will be appreciated that the manner in which authentication information is presented will depend on the nature of the information. Thus, if the authentication information is in the form of a username and password, the user can be presented with a suitable user interface on the touch screen 240 allowing them to authenticate themselves. An example interface is 20 shown in Figure 7A. In this instance, the interface 700 includes a username field 701, a password field 702 and an optional domain field 703, allowing the user to enter their username, password and optional domain information. Following this, the user can select an "OK" input command button 704 to indicate the information is completed, and to allow the process to proceed. 25 At this stage, the MFD 100 will arrange for authentication of the user to be performed, and this may be achieved in a suitable manner. Thus, for example, this can be achieved by transferring the authentication information to a remote server 130, allowing the server to compare the authentication information to previously determined authentication information stored in the database 140. Assuming the provided authentication information and the - 15 previously determined authentication information are in agreement, the server 130 can indicate to the MFD 100 that authentication is complete, allowing the process to continue. Alternatively however, any suitable authentication process can be used. After authentication is complete, the first set of permanent granted privileges PI can be 5 determined by retrieval from the user's personal profile. These are stored as current user privileges on the MFD 100. The user is then prompted for an authorisation token at step 602. The user can present the token, which is typically a suitable card or the like, to the recognition device 250. The authentication information may be checked at this point for validity as will be described in 0 more detail below. If such a token is presented, then at step 610, the user is temporarily granted additional access rights based on the second set of privileges P2, which in this example includes colour printing, associated with the respective token. Again, this is typically achieved by using the authorisation information to be used to allow the server 130 to retrieve the second set of 5 privileges from the database 140. The second set of privileges is used to update the current user privileges, so that the current user privilege set is determined by a combination of the first and second sets of privileges P1, P2. Whilst any form of combination may be used depending on the circumstances, the combination is typically in the form of a union of the first and second set of privileges P1 and 20 P2. Consequently, if a similar privilege (pl and p2) is present in both sets of privileges P1 and P2, respectively, when the union of the privileges is calculated, the higher privilege is included, and the lower one is omitted in the result of the union. The user may optionally be notified of the privileges granted to them via on-screen information, an example of which is shown in Figure 7B. In this example, the screen 710 25 includes a window 711 for displaying granted privileges, and an "OK" input button 712 for allowing the user to dismiss the information. As a result, the user is now able to perform the higher-privilege function, which in this example is printing in colour, at step 112.

- 16 In the event that the user does not provide the authorisation token at step 602, then the process proceeds to step 620, with the user only being allowed to perform a lower-privilege function such as printing in black/white. Thus, in this instance, with no additional privileges, the user's access rights are based solely on the first set of privileges P1, which in this 5 example provides an insufficient privilege set for performing the colour printing at step 612, but is sufficient to perform a lower privilege function such as black and white printing at step 620. Following the document processing the process ending at step 699. As part of the above process, if the additional access rights represented by the second set of privileges P2 were 0 temporarily granted to the user, then the additional rights can be revoked. Thus, for example, the revoking could occur after document processing has been performed, or after the user moves away from the processing system and the authentication token is no longer proximate to the token sensor. Alternatively, the authorisation information can have an expiration period so that revocation occurs after the authorisation period has expired, or if 5 a predetermined time period has elapsed after document processing has been performed. Revoking could also occur after a user login has expired, for example because the user has logged out, or after a login session has expired. It will be appreciated that revocation of the second set of privileges can be achieved by simply allowing the current user privilege set to be deleted, so that when a new current user 20 privilege set is generated during a next document processing operation, this is based solely on the first set of privileges P1. A second example use, in which multiple authorisation tokens are used, will now be described with reference to Figure 8. In this example, the process commences when the user approaches the MFD at step 800. In 25 this example, the user authenticates themselves by presenting authentication information at step 801, and it will be appreciated that this is typically achieved in a manner similar to that described above. At this stage, the set of permanent granted privileges P1 can be determined by taking them from the user's personal profile.

- 17 The user can then be prompted for an authorisation token, with the MFD 100 determining if this is presented at step 802. If such a token is presented, then at step 810, and is optionally deemed valid, the user is temporarily granted additional access rights provided by the second set of privileges P2 associated with that respective token. Again, this is achieved in a manner 5 similar to that described above. If the user has further authorisation tokens, they can indicate this using a suitable input command at step 811, allowing these to be presented at step 810. As each token is presented, the user is temporarily granted an associated set of privileges Pn associated with each respective token n. Once all the authorisation tokens have been presented, the user can 0 perform the higher privilege functions at step 812. Again, if no authorisation tokens are presented, then at step 820 the user can only perform the lower privilege functions, as defined in the first set of privileges Pl. At the end of the process at step 899, any additional privileges granted at step 810 are again typically revoked. 5 A third example use, in which a user selects a function to be performed prior to presenting an authorisation token, will now be described with reference to Figure 9. In this example, the process begins at step 900 when the user approaches the MFD 100. The user then authenticates themselves at step 901 by presenting authentication information, allowing the first set of permanent privileges P1 to be determined from the user's personal 20 profile. The user then selects a document processing function to be performed by the MFD 100 at step 902. At this stage, the MFD 100, or another processing system compares the user selected document processing function to available document processing functions indicated in the first set of privileges Pl. If the required document processing function is available and 25 hence doesn't require privileges above what the user already has, then it can simply be performed at step 920.

- 18 Otherwise, if higher privileges are required, the user is notified of this, by prompting the user to provide an appropriate authorisation token at step 904. This is typically achieved by presenting the user with a suitable user interface indicative of the required authorisation token, as shown for example in Figure 10A. 5 In this example, the interface 1020 includes a window 1021 indicative of the required privileges needed to perform the requested document processing operation. If the user is unable to present the token, they are able to click a "Cancel" button 1021 to continue using the system based on the permanent lower privileges defined in the first set of privileges Pl. After the user presents the token at step 905, the token can be checked for validity at step 0 910. This may be achieved in any one of a number of suitable manners. Thus, for example, the MFD 100 can provide the authorisation information associated with the authorisation token to another processing system, such as the server 130, allowing the server to determine if the authorisation information is valid. Validity of the authorisation information may depend on a number of factors. For example, 5 authorisation information can be determined to be invalid if the authorisation information has been used more than a predetermined number of times, if the authorisation token is no longer proximate to a token sensor, or if the authorisation information has expired. Accordingly, the remote server can compare information regarding the current or previous usage of the authorisation token as well as to other relevant criteria to determine if the authorisation 20 information is still valid. Thus, for example, each time an authorisation token is used, the server 130 can compare the number of times it has previously been used, as determined from usage information, to a predetermined number to determine if a usage limit has been reached. If not, then the server 130 can indicate that the authorisation can be used. 25 In addition to this, the server 130 can access information indicating if the authorisation token is invalid for any other reason, such as if the authorisation token is indicated to be misplaced or stolen.

- 19 A further issue is that the authorisation information may not be valid for the identified user, for example in the event that the user has been prevented for using authorisation tokens for any reason. In this instance, this information may be indicated in either the user's profile, or by including an indication of the user identity associated with the authorisation information in 5 some manner. In this example, the server 130 or MFD 100 use the user identity to determine if the user is excluded from using the authorisation information, in which case the authorisation information is deemed invalid. If it is determined that the authorisation token is invalid, then the user is presented with an indication of this, which can be achieved for example using the user interface of Figure 10B. 0 In this example, the user interface 1030 includes an indication that the authorisation token is invalid, together with an "OK" button 1031, allowing the user to select this. At this point the process can move onto step 999 and end or proceed with allowing document processing only in accordance with the first set of privileges. However, if it is determined that the authorisation token is valid, then the process can move 5 onto step 920, allowing the requested document processing function to be performed before the process ends at step 999. A fourth example use, in which privileges granted to a user are made to persist permanently, will now be described with reference to Figure 11. In this example, a manager and an employee both approach an MFD 100 at step 1100. At 20 step 1101, the employee presents authentication information, allowing the employee to be authenticated and the first set of permanent granted privileges P1 to be determined from the user's personal profile. At step 1102, an authorisation token is presented, allowing the user's first set of privileges P1 to be temporarily elevated with a second set of privileges in a manner similar to that 25 described above. Accordingly, this involves forming a set of current user privileges from a union of the first and second sets of privileges. At step 1103, the manager presents their own authentication information, allowing the manager's identity to be authenticated in a similar manner to the employees. Following this, - 20 at step 1104, the manager is able to make the temporarily granted privileges to the user persist after said user and said manager both leave the MFD at step 1199. This is typically achieved by overwriting the first set of privileges, with the current user privileges, so that the first set of privileges becomes a union of the first and second sets of privileges P1, P2. As a 5 result, the higher privileges associated with the authorisation token permanently apply to the employee. This therefore provides a mechanism for permanently upgrading said user's privileges. It will also be appreciated that this technique could be adapted to allow a user's privileges to be permanently downgraded if required. A fifth example use, in which privileges are associated with an authorisation token, will now 0 be described with reference to Figure 12. In this example, the manager approaches an MFD 100 or another computing device such as a computer system 120 at step 1200. The manager provides authentication information to the processing system allowing the manager's MFD privileges set P1 to be determined from their personal profile at step 1201. A possible privileges set for a manager and a user is presented 5 in the examples above. The manager then presents a blank authorisation token to the MFD 100 or computer system 120, which is not yet associated with any privileges, at step 1202. The manager then selects a second set of privileges P2, which is a subset of the manager's own first set of privileges P1, using an appropriate user interface. Thus, in the above example, the manager could select a 20 printing in colour to A4 paper only privilege. The manager then selects to persist the privileges to the authorisation token at step 1204, causing the MFD 100 or computer system 120 to generate data indicative of the second set of privileges at step 1204. This data may then be stored on the authorisation token, or alternatively stored separately in a remote database or the like, together with the token ID of 25 the respective authorisation token, thereby allowing the authorisation information to be subsequently retrieved. This causes the authorisation token to be associated with the second set of privileges P2 so that in future, anyone possessing the authorisation token is able to print in colour to A4 paper only.

-21 In addition to the processes described above, the system also allows for usage of authorisation tokens to be logged, as will now be described with reference to Figure 13, which shows example log entries. In particular, in this example, when a document processing function is performed, and/or 5 when an authorisation token is used, the MFD 100 performing the function will automatically update a usage log with details of the function performed. The log may be stored on the MFD 100, the authorisation token itself, or on a remote server 130 or database 140. As shown in Figure 13, the log is typically in the form of a table 1300. In this example, the columns of data in the table include a username column 1301, an action performed column 0 1302, a page size column 1303 and an authorisation token ID column 1304. The username is retrieved by the processing system from the authentication information presented by the user, with the action and page size information being provided by the MFD 100. The token ID which identifies each authorisation token can be retrieved from the token itself when the authorisation token is used. 5 In this example, the first entry in the table depicts a regular user printing a black/white A4 page without any privilege tokens presented, as shown at 1310. A second entry at 1311 depicts the user printing to colour A4, this time with the authorisation token having a token ID 1234. The third entry at 1312 depicts a user printing to colour A3, this time using two tokens to elevate privileges, the tokens have token IDs of 1234 and 5678, respectively. The 20 last entry shown at 1313 depicts the manager printing to colour A3 without any privilege elevation tokens. It will be appreciated that maintaining a log in this manner links each action to both the user that carried out the action and the owner of the authorisation token that authorised the action by way of the indicated authorisation token ID. 25 A number of further features may also be implemented. For example, when a user requires an authorisation token, the user can be provided with an indication of the location of the token. This is typically achieved by having the processing system determine the authorisation token required to perform document processing and then - 22 determine a location of the authorisation token, with an indication of the determined location being presented to the user, for example using the touch screen 240. The manner in which the location is determined will vary depending on the circumstances. In one example, the MFD 100 can determine the owner of a required authorisation token, and 5 provide an indication of this to the user. This information may be stored in the database 140 together with the indication of the second sets of privileges associated with each authorisation token. Alternatively, the location may be determined at least in part from the usage log. Thus, for example, the log can additionally indicate on which MFD 100 document processing was last 0 performed, allowing the MFD location to be determined. Additionally and/or alternatively, the authentication of users, allows the last user of the authorisation token to be similarly identified, which again can assist in allowing authorisation tokens to be located. A further variation is to allow a token owner, such as a manager, to be contacted when an authorisation token is used. In this example, when an authorisation token is presented, or 5 when or after document processing is performed, the processing system can determine an owner associated with the authorisation information and then provide a usage notification to the owner. Thus, for example, owner contact details can be retrieved from the authorisation token, the remote server 130 or the database 140. The contact details can then be used to send the notification to the manager. The notification may be sent by any suitable 20 mechanism such as by email, SMS (Short Message Service), or the like, and can include usage information allowing authorisation token owners to monitor usage of their tokens. It will be appreciated that the above described processes allow an MFD user to have a greater set of privileges then just their personal privilege set. In one example, an authenticated user has a first set of privileges P1. The user obtains a privilege elevation token from an 25 authorising party which is associated with a second set of privileges P2 being provided by an authorisation token P2. Upon logging in and presenting the token, the user's privilege set becomes the union of P1 and P2. In the case that a privilege (pl and p2) is present in both P1 and P2, respectively, -23 when the union of the privileges is calculated, the higher privilege is included, and the lower one is omitted in the result of the union. As a result, when the user requests a subsequent document processing function, this will be permitted in the event that it satisfies the combination of the first and second sets of 5 privileges. Furthermore, the action can be carried out in the authentication context of the user, with a log being generated, so that the document processing function can be tracked to both the user and a manager, via the use of the specific authorisation token. When said user is authenticated again at a later point in time, their privileges revert to the o original set of privileges P1 as the second set of privileges P2 are only temporarily granted. Consequently, if said user wishes to get those privileges back, they have to obtain the token and present it as before. It will be appreciated that this provides an easy mechanism for privileges associated with users to be temporarily elevated whilst retaining the security provided by having assigned 5 privileges. The term document processing is intended to encompass any document processing function utilising, at least in part, a hard copy document. The term therefore encompasses functions such as scanning, copying, printing and faxing of documents. It will be appreciated from this that whilst the above examples have been described with 20 respect to MFDs, the techniques may be applied to any devices that are capable of performing document handling jobs, such as printers, copiers, scanners, facsimile machines, or the like. The term processing system is also understood to encompass any one of the processing systems provided in the network environment, including but not limited to one or more of the computers 120, the servers 130, and the controllers implemented within the MFDs 100.

- 24 The foregoing describes only some embodiments of the present invention, and modifications and/or changes can be made thereto without departing from the scope and spirit of the invention, the embodiments being illustrative and not restrictive. In the context of this specification, the word "comprising" means "including principally but 5 not necessarily solely" or "having" or "including", and not "consisting only of". Variations of the word "comprising", such as "comprise" and "comprises" have correspondingly varied meanings.