Reading device

Abstract

To provide a reading device that can make an appropriate user execute the cancellation of scanning.SOLUTION: When a controller 11 of an MFP 10 receives user authentication information together with a pull scan execution instruction (S92: YES), it displays a scan execution screen 69 that does not include a cancel button 73 on a touch panel 16a (S98). Also, when the controller 11 has not received user authentication information together with the instruction for executing the pull scan (S92: NO), the controller 11 displays a scan execution screen 71 including the cancel button 73 on the touch panel 16A. The controller 11 cancels the pull scan being executed in response to receiving the operation of the cancel button 73 (S112: NO, S116).SELECTED DRAWING: Figure 11

Description

Technical Field

[0001] The present invention relates to a reading device that reads a document by a scanner.

Background Art

[0002] Patent Document 1 describes a reading device capable of executing a pull scan that causes a scanner to read a document according to an execution instruction from an external device. In the reading device, in advance, a list of users who are permitted to execute the pull scan is registered, and when an execution instruction for the pull scan is received, it is authenticated whether the user who gave the execution instruction matches the registered user. Then, if the authentication is successful, the reading device starts the pull scan.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In scanning using a reading device, there may be a case where it is desired to cancel the execution after instructing the execution of the scan. The reading device of Patent Document 1 has room for improvement in terms of which user should be permitted to execute the cancellation.

[0005] The present invention has been made in view of the above problems, and an object thereof is to provide a reading device that can cause an appropriate user to execute the cancellation of the scan.

Means for Solving the Problems

[0006] To solve the above problems, the reading device disclosed in this embodiment includes a touch panel, a scanner, and a controller. The controller is capable of executing a pull scan that causes the scanner to read a document according to an execution instruction from an external device. The controller is configured to start the pull scan and display a scanning-in-progress screen on the touch panel in response to receiving the execution instruction for the pull scan. When the controller receives user authentication information together with the execution instruction for the pull scan, the controller causes the touch panel to display the scanning-in-progress screen that does not include a cancel button. When the controller does not receive the user authentication information together with the execution instruction for the pull scan, the controller causes the touch panel to display the scanning-in-progress screen that includes the cancel button, and is configured to cancel the ongoing pull scan in response to receiving an operation on the cancel button.

[0007] Also, to solve the above problems, the reading device disclosed in this embodiment includes a display, a hardware key, a scanner, and a controller. The controller is capable of executing a pull scan that causes the scanner to read a document according to an execution instruction from an external device. The controller is configured to start the pull scan and display a scanning-in-progress screen on the display in response to receiving the execution instruction for the pull scan. When the controller receives user authentication information together with the execution instruction for the pull scan, during the execution of the pull scan, even if a cancel operation is performed on the hardware key, the controller does not cancel the ongoing pull scan. When the controller does not receive the user authentication information together with the execution instruction for the pull scan, during the execution of the pull scan, the controller is configured to cancel the ongoing pull scan in response to a cancel operation being performed on the hardware key.

[0008] In the above configuration, when receiving user authentication information together with an instruction to execute a pull scan, the reading device can be made not to cancel the pull scan. Thereby, it is possible to prohibit a user other than the user indicated by the user authentication information from canceling the pull scan with the reading device. Also, when not receiving user authentication information together with the instruction to execute the pull scan, the cancellation of the pull scan can be executed by operating a cancel button or a hardware key. For a scan job without user authentication information, cancellation can be permitted by a user operation.

Effect of the Invention

[0009] According to the present invention, an appropriate user can be made to execute the cancellation of a scan.

Brief Description of the Drawings

[0010]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Embodiments for Carrying Out the Invention

[0011] Embodiments of the reading device will be described using an MFP (abbreviation for Multi Function Peripheral). As shown in FIG. 1, the MFP 10 includes a controller 11, a memory 12, a printer 13, a FAX IF 14, a scanner 15, a user IF 16, a USB IF 17, and a communication IF 18. These components are communicably connected to each other via a bus 1.

[0012] The printer 13 prints an image on a recording medium such as a sheet or a disk. The sheet is, for example, paper or an OHP sheet. As the printing method of the printer 13, an inkjet method, an electrophotographic method, or the like can be adopted. The scanner 15 has a reading sensor such as a CCD or a CIS, for example, and generates image data corresponding to the reading of a document.

[0013] User IF 16 is an interface capable of receiving various operations for MFP 10. User IF 16 includes a touch panel 16A including a liquid crystal display and various operation keys, etc. The various operation keys include a cancel key 16B described later. The cancel key 16B is an example of the hardware key in this specification. USB IF 17 can detachably connect a storage medium corresponding to the USB standard, etc., and can read and write data by communication conforming to the USB standard. The storage medium corresponding to the USB standard is, for example, a USB memory, etc. MFP 10 is connected to a network via communication IF 18, and communicates with PC 40 via the network according to a predetermined protocol (such as TCP / IP). As the communication IF 18, a wired LAN interface, a wireless LAN interface, etc. can be adopted.

[0014] Controller 11 is a processing device including, for example, a CPU, etc. Memory 12 is configured by combining a volatile memory such as a RAM, a non-volatile memory such as an NVRAM, a ROM, etc. As the non-volatile memory, an SSD, an HDD, etc. may be used. The buffer provided in controller 11 used when executing various programs may also be regarded as a part of memory 12. Incidentally, memory 12 may be a storage medium readable by controller 11. The storage medium readable by controller 11 is a non-transitory medium. The non-transitory medium includes, in addition to the above examples, recording media such as CD-ROMs and DVD-ROMs. Also, the non-transitory medium is a tangible medium. On the other hand, an electrical signal carrying a program downloaded from a server on the Internet, etc. is a computer-readable signal medium which is a kind of computer-readable medium, but is not included in the non-transitory computer-readable storage medium.

[0015] In the memory 12, a control program 2 is stored as a program executable by the controller 11. The control program 2 is, for example, firmware that comprehensively controls each part of the MFP 10. The controller 11 controls each device connected to the bus 1 by executing the control program 2. In the present embodiment, mainly, the processing of the controller 11 according to the instructions described in the program is shown. That is, the processing such as "judgment", "specification", "acquisition", "reception", "control", etc. in the following description represents the processing of the controller 11. Note that "acquisition" is used as a concept that does not require a request. That is, the process of the controller 11 receiving data without a request is also included in the concept of "the controller 11 acquires data". Also, the "data" in this specification is represented by a bit string readable by the controller 11. And data having the same substantial meaning content but different formats shall be treated as the same data. The same applies to the "information" in this specification.

[0016] Further, the control program 2 includes, for example, an EWS (Embedded Web Server) program that functions as a Web server. The controller 11 can cause the MFP 10 to function as a Web server by executing the EWS program. The Web server functioning in the MFP 10 is also referred to as EWS. The controller 11 can cause a browser 41 (to be described later) of the PC 40 to display a predetermined Web page by transmitting Web page data for displaying the Web page to the PC 40. Transmitting the Web page data is also described as providing a Web page.

[0017] Next, the configuration of the PC 40 will be described. The PC 40 includes a communication IF (not shown), a memory, a controller, a display, and a user IF. The memory of the PC 40 stores an OS and a browser 41. The browser 41 can display a web page corresponding to the web page data transmitted from the MFP 10 on the display. The PC 40 is an example of an external device in this specification. Note that the external device is not limited to the PC 40, and other devices that can transmit an execution instruction for the pulse scan described later to the MFP 10, such as mobile terminals such as smartphones and tablets, may also be used.

[0018] Next, the "Secure Function Lock" function will be described. The MFP 10 of the present embodiment has a "Secure Function Lock" function (hereinafter sometimes referred to as the SFL function). The SFL function is a function that sets whether to permit or not permit each function of the MFP 10 for each user and restricts the execution of functions set not to be permitted. Setting not to permit each function of the MFP 10 is also described as restricting. The controller 11 receives, for example, settings such as the enable / disable of the SFL function, user registration, password registration, and function restriction settings for each user via the EWS. The setting value related to function restriction can also be said to be a setting value related to permission. Specifically, it is a setting value indicating whether to permit or not permit each function. The received information is registered in the SFL database 19 of the memory 12. Note that the method of receiving each setting value is not limited to the method of receiving via the EWS, and a method of receiving via the user IF 16 may also be used.

[0019] FIG. 2 shows a restriction setting screen 30 for receiving functions restricted for each user. The controller 11 provides a web page to the browser 41 of the PC 40 that has accessed the EWS, for example. When an administrator login operation is performed on the provided web page, the controller 11 provides the PC 40 with a web page for setting the enable / disable of the SFL function and a web page showing the restriction setting screen 30 shown in FIG. 2.

[0020] The restriction setting screen 30 has a restriction specification field 31 that accepts the specification of the users and functions to be restricted in the SFL function. The restriction specification field 31 has a user specification field 32 (32A, 32B) for specifying the users to be restricted, and a function specification field 33 for specifying whether to permit or not permit each function. There are a plurality of user specification fields 32. Among the user specification fields 32, the "Public Mode" 32A is a field indicating that the target of the SFL function is the state of not being logged in (hereinafter sometimes referred to as the logged-out state). It can also be said that it is a field indicating setting restrictions without specifying a user. The individual user field 32B is a field for inputting the user name indicating the user targeted by the SFL function. That is, it can also be said that it is a field indicating setting restrictions for a specific user. To the right of each of the plurality of user specification fields 32, there is a function specification field 33. The function specification field 33 to the right of an individual user specification field 32 is a field indicating whether to permit or not permit each individual function corresponding to the user indicated by the user specification field 32.

[0021] The function specification field 33 is also a field that accepts the specification of the functions to be restricted by the SFL function. The function specification field 33 has check boxes indicating the presence or absence of setting restrictions for each of the functions of "Print", "Copy", "Scan", "FAX", "USB", and "Web Connection" of the MFP 10. Note that the function "Scan" corresponds to the push scan described later. In the function specification field 33, the functions with a check are the functions specified as not setting restrictions, that is, the functions for which execution is permitted, and the functions without a check are the functions specified as setting restrictions, that is, the functions for which execution is not permitted. Also, the function "FAX" includes the individual functions of "FAX transmission" and "FAX reception", and there are check boxes for each individual function. The function "USB" includes the individual functions of "USB direct print" and "Scan to USB", and there are check boxes for each individual function. "Web Connection" includes the individual functions of "Upload" and "Download", and there are check boxes for each individual function. Note that the types of restriction items shown in FIG. 2 are examples.

[0022] In the example shown in FIG. 2, in the function designation field 33 of “Public Mode” 32A, the check is not made only for the function “Scan”, and the checks are made for other functions. In this case, in the logged-out state where no one is logged in to the MFP 10, the execution of the function “Scan” is restricted, and the execution of other functions is not restricted. Similarly, for “User A” and “User B” in the individual user field 32B, each function is restricted or not restricted according to the check items. For the sake of convenience, “restricted or not restricted” may be abbreviated as “restricted”. The controller 11 restricts functions based on the set values of the logged-in user in a state where the SFL function is valid and any user is logged in (hereinafter sometimes referred to as the logged-in state). Further, when the instruction from the PC 40 requires authentication, the controller 11 restricts functions based on the set values of the authenticated user. When the controller 11 is operated by an unillustrated decision button, it updates each set value in the SFL database 19 based on the input to the restriction setting screen 30.

[0023] Note that the controller 11 stores and uses various set values not only in the SFL database 19 but also in the memory 12. Storing the set value in the memory 12 may be described as setting for the sake of convenience. That the set value is stored in the memory 12 may be described as set, set up, set to be, etc. for the sake of convenience.

[0024] Next, the procedure of the process executed by the controller 11 when the user uses the "Scan" function of the MFP 10 will be described. The MFP 10 can execute "Push Scan" and "Pull Scan" as the "Scan" function. The controller 11 generates scan data using the image data output by the scanner 15 reading the original document. Scan data is also a type of image data. "Push Scan" generates scan data by causing the scanner 15 to read the original document in response to an execution instruction according to an operation on the user IF 16, and outputs the generated scan data to the output destination according to the execution instruction. For example, it is a scan that transmits the scan data. As the output destination of the data by push scan, a PC 40, a device connected to the MFP 10, for example, a device connected via the USB IF 17 or the communication IF 18 can be specified. "Pull Scan" is a scan that generates scan data by causing the scanner 15 to read the original document in response to an execution instruction transmitted from an external device according to an operation on the external device, and transmits the generated scan data to the device that is the transmission source of the execution instruction. In the present embodiment, the external device is the PC 40.

[0025] For example, after the power of the MFP 10 is turned on and the control program 2 is executed to start the system, the controller 11 starts the scan control process shown in FIG. 3. Note that the condition for starting the process in FIG. 3 is not limited to the condition for starting the system. For example, the controller 11 may start the process in FIG. 3 on the condition that it returns from the power saving mode for suppressing power consumption. In the following description, first, it will be described assuming that the restriction setting values shown in FIG. 2 are set in the SFL database 19.

[0026] First, in step 1, the controller 11 determines whether or not it has received an execution instruction for scanning. Hereinafter, the steps will be described as "S". The controller 11 executes the process of S1 until it determines that it has received an execution instruction for push scan or pull scan (S1: NO). When it determines that it has received it (S1: YES), it executes the scan request process of S2.

[0027] As shown in FIG. 4, in S10, the controller 11 determines whether or not it has received an execution instruction for push scan. Specifically, when the controller 11 receives an execution instruction to start the execution of the function "scan" by an operation on the user IF16 of the MFP 10, it determines that it has received an execution instruction for push scan (S10: YES), and executes the request process for push scan in S11. For example, in response to receiving an operation on the user IF16, the controller 11 transmits a push scan request to an external device (in this example, the PC 40). The external device that has received the request returns an execution instruction for "scan" to the MFP 10. When receiving this reply, the controller 11 determines that it has received an execution instruction for push scan. Also, when an operation to start scan is performed in the external device and the controller 11 has received an execution instruction transmitted from the external device, it determines that it has received an execution instruction for pull scan (S10: NO), and executes the request process for pull scan in S12.

[0028] Note that the execution instruction for "scan" may include information indicating whether it is an execution instruction in response to receiving an operation on the user IF16 or an execution instruction in response to an operation in the external device. The controller 11 may determine whether it is an execution instruction for push scan or an execution instruction for pull scan based on that information. Also, in response to receiving an operation on the user IF16, the controller 11 may determine that it has received an execution instruction for push scan without transmitting a request to the external device, and execute S11.

[0029] As shown in FIG. 5, in S11, the controller 11 restricts or executes push scanning according to the restriction setting value registered in the SFL database 19. First, the processing in the logged-out state will be described. The logged-out state where no login has been made to the MFP 10 is also conveniently referred to as "Public Mode". For example, the SFL database 19 stores information indicating whether the function "SFL" is enabled "ON" or disabled "OFF" (hereinafter sometimes referred to as the function "SFL" information). In S21, the controller 11 determines the function "SFL" information of the SFL database 19 stored in the memory 12. When the controller 11 determines that the function "SFL" information indicates disabled (S21: NO), it executes S29 and instructs the scanner 15 to start scanning so as to read the document set on the platen. That is, the controller 11 executes the process without imposing a restriction on push scanning and ends the processes of FIGS. 4 and 5.

[0030] In this example, it is assumed that information indicating enabled "ON" is set as the function "SFL" information of the SFL database 19. Therefore, the controller 11 determines that the function "SFL" is enabled (S21: YES). In S23, the controller 11 checks whether it is in the logged-in state logged in by an operation on the user IF 16. In this example, since it is in the logged-out state (S23: NO), the controller 11 refers to the restriction setting value corresponding to the function "scan" in "Public Mode" in the SFL database 19 (S24).

[0031] As shown in FIG. 2, since the restriction setting value corresponding to the function "Scan" in "Public Mode" is "Restriction" (S25: YES), the controller 11 notifies an error indicating that the function "Scan" cannot be executed (S28). In this embodiment, the controller 11 notifies by causing the user IF 16 to display an error screen indicating that the function "Scan" cannot be executed. That is, the controller 11 restricts push scanning in the logged-out state. In this embodiment, the restriction on the function "Scan" means not executing the scan process. As a restriction on the function "Scan", a configuration may be adopted in which the quality of the scan to be executed is reduced. Further, as a restriction on the function "Scan", a configuration may be adopted in which a special permission operation by the administrator is further required for the execution of the scan. The controller 11 ends the processes of FIGS. 4 and 5. Incidentally, if the restriction setting value corresponding to the function "Scan" in "Public Mode" is "Permission" (S25: NO), the controller 11 instructs the scanner 15 to start scanning (S29).

[0032] Next, the process when "User A" is logged in to the MFP 10 will be described. Since the controller 11 is in a state where "User A" is logged in (S23: YES), in S26, the controller 11 refers to the restriction setting value corresponding to the function "Scan" for User A in the SFL database 19. As shown in FIG. 2, since the restriction setting value corresponding to the function "Scan" for "User A" is set to "Restriction", the controller 11 makes an affirmative determination in S27 (S27: YES), notifies the error indicating that the scan cannot be executed as already described (S28), and ends the processes of FIGS. 4 and 5. Incidentally, when "User B" is logged in, since the restriction setting value "ON" that does not restrict the function "Scan" for "User B" is registered in the SFL database 19 (S27: NO, see FIG. 2), the scan process is started (S29).

[0033] Here, the login process will be described. In the SFL database 19, user authentication information for "User A" and "User B" is registered. The registered user authentication information is a user ID and a password corresponding to the user ID. When the user ID and the password corresponding to the user ID registered in the SFL database 19 are input via the user IF 16 in the login process, the MFP 10 performs various processes assuming that it has entered the login state corresponding to the input user authentication information. For example, when the user ID "User A" and the corresponding password are input, the controller 11 causes the MFP 10 to perform various processes assuming that it has entered the login state corresponding to the input "User A". It can also be said that the user authentication information registered in the SFL database 19 is the user authentication information of the users permitted to log in to the MFP 10. Note that the login state corresponding to the user authentication information is also described as the state in which the user indicated by the user authentication information has logged in. Also, the login state corresponding to "User A" is also described as the state in which "User A" has logged in. Also, when the user indicated by the user authentication information is in the logged-in state, the user indicated by the user authentication information is also referred to as the "logged-in user". Note that the input of the user ID and password in the login process may be performed by bringing an ID card corresponding to the user ID registered in the SFL database 19 close to or into contact with the MFP 10. Also, the information used in the login process may be stored in an area other than the SFL database 19 in the memory 12. In this case, the controller 11 may refer to that area in the memory 12 during the login process and during the process of FIG. 8.

[0034] Next, the processing executed by the controller 11 when receiving an instruction to execute a pull scan from the PC 40 will be described. First, the processing when the MFP 10 is in the logged-out state, that is, in the "Public Mode", and "User A" operates the PC 40 to execute a pull scan will be described. As shown in FIG. 6, when starting the processing of S12, the controller 11 determines whether the execution of the pull scan is set to be valid or invalid in the MFP 10 (S31). For example, the controller 11 determines based on the information stored in the memory 12 indicating whether the pull scan is set to be valid or invalid, separately from the SFL database 19. In this example, assuming that the pull scan is set to be valid (S31: YES), the controller 11 executes the user authentication necessity determination process of S32. By this user authentication necessity determination process, the controller 11 specifies whether user authentication is required for the execution instruction of the pull scan using the restriction setting value corresponding to the push scan in the "Public Mode". Note that when the pull scan is set to be invalid in the MFP 10 (S31: NO), the controller 11 notifies the PC 40 that the pull scan cannot be executed (S41). That is, when the pull scan is set to be invalid in the MFP 10, the pull scan is not executed regardless of who is logged in to the MFP 10.

[0035] As shown in FIG. 7, when starting the processing of S32, the controller 11 refers to the function "SFL" information in the SFL database 19 and determines whether the function "SFL" is set to be valid (S51). In this example, since information indicating validity is set as the function "SFL" information in the SFL database 19 (S51: YES), S52 is executed, and the restriction setting value corresponding to the function "scan" in the "Public Mode" of the SFL database 19 is referred to (see FIG. 2). Referring to the SFL database 19, it is determined whether the restriction setting value indicates that the push scan in the logged-out state is restricted.

[0036] In this example, as shown in FIG. 2, since a limit setting value "limit" indicating a limit is registered for the function "scan" in "Public Mode" (S53: YES), S54 is executed. The controller 11 sets in S54 that user authentication is required for an instruction to execute a pulse scan. For example, the controller 11 sets a value indicating that user authentication is required in a necessity determination flag.

[0037] The controller 11 executes S33 in FIG. 6. Since a value indicating that user authentication is required is set in the necessity determination flag, that is, since user authentication is required (S33: YES), in S34, the controller 11 performs communication (for example, a GET request by HTTPS communication) to request user authentication information necessary for user authentication from the PC 40. When the PC 40 receives a request for user authentication information from the MFP 10, the PC 40 transmits response data including, for example, the user authentication information of the user operating the PC 40 to the MFP 10. Specifically, the user authentication information is a user ID and a password. This user authentication information is an example of the user authentication information received together with an instruction to execute a pulse scan. In this case, the PC 40 transmits response data including the user authentication information of "User A". The PC 40 may transmit response data including the user authentication information of the user logged in to the PC 40. Alternatively, the PC 40 may transmit response data including the user authentication information input by the user when logging in to the PC 40. Also, after receiving the GET request, the PC 40 may receive a user ID and a password from the user and transmit them as response data.

[0038] If the PC 40 does not transmit user authentication information in response to a GET request from the MFP 10, the user authentication process in S36 described later cannot be executed. Therefore, when the controller 11 does not receive user authentication information from the PC 40 (S35: NO), in S41, the controller 11 notifies the PC 40 that it cannot execute a pulse scan.

[0039] Here, assuming that the controller 11 has received user authentication information from the PC 40 (S35: YES), it executes the user authentication process in S36. As shown in FIG. 8, when the controller 11 starts the process in S36, it checks whether the user authentication information received from the PC 40 (information indicating User A in this example) is registered in the SFL database 19 as information to be used for the login process (S60). As shown in FIG. 2, the SFL database 19 has registered at least user authentication information regarding "User A" and "User B", that is, information indicating users who can log in to the MFP 10. Since the user authentication information received from the PC 40 by the controller 11, that is, the user ID and password, is registered in the SFL database 19 (S61: YES), it executes S62 and sets that the user authentication has succeeded. For example, the controller 11 sets a value (true) indicating success in an authentication completion flag indicating the success or failure of user authentication. Incidentally, when the user authentication information received from the PC 40 by the controller 11 is not registered in the SFL database 19 in S61 (S61: NO), it sets a value (false) indicating that the user authentication has failed in the authentication completion flag (S63). When a value (false) indicating that the user authentication has failed is set, the controller 11 determines in S37 of FIG. 6 that the user authentication has failed (S37: NO) and executes S41.

[0040] In this example, the controller 11 determines in S37 of FIG. 6 that the user authentication has succeeded (S37: YES) and executes the scan permission confirmation process in S38. As shown in FIG. 9, when the controller 11 starts the process in S38, it determines whether it is in the logged-in state, that is, whether it is in "Public Mode" (S70). In this example, since it is not in "Public Mode" (S70: NO), it executes S74.

[0041] The controller 11 refers to the limit setting value of the "Scan" function for the user who has successfully passed the user authentication in S36 as already described in S74. In this example, for the "Scan" function corresponding to "User A" in the SFL database 19, a limit setting value "Restriction" indicating a restriction is registered (see Figure 2). Therefore, the controller 11 determines in S75 that there is a restriction on the "Scan" function (S75: YES), and in S73, sets a value indicating that the start of scanning is not permitted in the scan permission flag.

[0042] In S39 of Figure 6, since the controller 11 has a value indicating that the start of scanning is not permitted set in the scan permission flag, that is, the scan process is not permitted (S39: NO), it executes S41. Since there is a restriction on push scanning for "User A", even if the authentication by the user authentication process in S36 is successful, pull scanning is restricted. Then, the controller 11 ends the process of Figure 6.

[0043] Next, the process when "User A" operates the PC 40 to execute pull scanning while logged in to the MFP 10 will be described. Also in this example, the controller 11 executes the processes of S31 to S37 in Figure 6 already described. In S32, the controller 11 identifies that push scanning in "Public Mode" is restricted, and in S33, determines that user authentication is required (S33: YES). Then, the controller 11 executes S38 on the condition that the user authentication is successful (S37: YES).

[0044] In S70 of FIG. 9, since the controller 11 is in the state where "User A" has logged in (S70: YES), it executes S71 and determines whether the user who requested the pulse scan matches the logged-in user. Specifically, the controller 11 compares the user authentication information used in the user authentication process of S36 described above with the user authentication information of the logged-in user to determine whether the users match. That is, the controller 11 determines whether the user who operates the PC 40 to request the start of the pulse scan matches the user logged in to the MFP 10. Therefore, the user who requested the pulse scan can also be said to be the user indicated by the user authentication information received together with the execution instruction of the pulse scan.

[0045] When the controller 11 determines that the users match (S72: NO), it executes S74. In S74, the controller 11 determines whether a restriction on the function "Scan" is set for the user who succeeded in user authentication in S36. Since the function "Scan" for the user A who succeeded in user authentication is restricted in the SFL database 19 (S75: YES), the controller 11 executes S73 and does not permit the start of the scan process (pulse scan). The controller 11 executes S39 of FIG. 6. As already described, since the scan process is not permitted (S39: NO), it executes S41.

[0046] Also, when the controller 11 determines in S72 of FIG. 9 that the users do not match (S72: YES), it executes S73 and does not permit the start of the scan process (pulse scan). For this reason, in FIG. 6, since the scan process is not permitted (S39: NO), the controller 11 executes S41.

[0047] Also, in S72, the condition for determining that the user who requested the pull scan matches the logged-in user is not limited to the condition that the user names exactly match. That the user authentication information in this specification corresponds does not necessarily mean that the user names exactly match. For example, it may be determined that the users match on the condition that a part of the user names match. Or, when information indicating substantially the same user is shown instead of a match of user names, it may be determined that the users match. For example, when one of two pieces of user authentication information is a user ID and the other is a user name indicating that user ID, it may be determined that the users match. Also, when information indicating the group to which the user belongs is included as user authentication information, it may be determined that the users match on the condition that they are in the same group.

[0048] Next, the processing when "User B" operates the PC40 to execute a pull scan in the state "Public Mode" where the MFP10 is not logged in will be described. Also in this example, the controller 11 executes the processing of S31 to S37 in FIG. 6 which has already been described. The controller 11 is in "Public Mode" in S70 of FIG. 9 (S70: NO), and since "permit" is registered in the restriction setting value corresponding to the "scan processing" function of "User B" who has successfully authenticated (S75: NO), in S76, a value indicating permission to start scanning is set in the scan enable flag. In S39 of FIG. 6, since the controller 11 has a value indicating permission to start scanning set in the scan enable flag (S39: YES), similar to S29, it instructs the scanner 15 to start scanning (S40). That is, since there is no restriction set on push scanning for "User B", the controller 11 executes a pull scan on the condition that the authentication is successful.

[0049] Next, the processing when "User B" performs a pull scan while logged in to the MFP10 will be described. Also in this example, the controller 11 executes the processes of S31 to S37 in FIG. 6 which have been described above. Since the controller 11 is in the state where "User B" is logged in at S70 in FIG. 9 (S70: YES), it executes S71 and determines whether the user who requested a pull scan by operating the PC 40 matches the logged-in user of the MFP10. When the controller 11 determines that the users match (S72: NO), it executes S74. Since the restriction setting value corresponding to the "Scan" function of "User B" is "Permit" (S75: NO), it permits the start of the pull scan (S76). Incidentally, when the controller 11 determines in S72 of FIG. 9 that the users do not match (S72: YES), it does not permit the start of the pull scan (S73). That is, even when user authentication has succeeded for "User B" and the restriction setting value corresponding to the "Scan" function of "User B" in the SFL database 19 is "Permit", if the user who requested the pull scan does not match the logged-in user of the MFP10, the pull scan is not permitted.

[0050] Next, unlike the example of the SFL database 19 shown in FIG. 2, an example of executing a pull scan when a restriction setting value of "permitted", which does not show a restriction for the function "scan" in "Public Mode", is registered will be described. When the controller 11 makes an affirmative determination in S31 of FIG. 6 (S31: YES), it executes S32. In S51 of FIG. 7, since the function "SFL" is valid "ON" in the SFL database 19 (S51: YES), it executes S52 and refers to the restriction setting value of the function "scan" in "Public Mode". In this example, since the restriction setting value of "permitted" for the function "scan" in "Public Mode" is registered in the SFL database 19 (S53: NO), it executes S55. In S55, the controller 11 sets a value indicating that user authentication is not required for the execution instruction of the push scan in the necessity determination flag. Then, in S33 of FIG. 6, the controller 11 determines that user authentication is not required (S33: NO) and instructs the scanner 15 to start the scan (S40). That is, in this example, since the push scan in "Public Mode" is not restricted, the pull scan is not restricted for anyone.

[0051] Next, an example in which information indicating invalid "OFF" is set as the function "SFL" information in the SFL database 19 will be described. When the controller 11 makes an affirmative determination in S31 (S31: YES), it executes S32. In S51 of FIG. 7, since the function "SFL" is invalid "OFF" (S51: NO), it executes S55. That is, in this example, since the function "SFL" is invalid, the pull scan is not restricted for anyone.

[0052] Next, the operation procedure of the scanning process and the screen during the scanning process will be described. FIG. 15 shows a screen displayed on the user IF 16, and shows the screen transition from the standby screen to the start of the execution of the pull scan after the login operation. As shown in FIG. 15(a), the controller 11 displays icons 61A to 61E for executing each function such as FAX, copy, scan, print, and settings on the standby screen 60. Further, the controller 11 displays an information bar 62 for displaying login information and a tray icon 63 for selecting a paper feed tray for printing or the like.

[0053] When the information bar 62 is touched, the controller 11 displays a user change screen 65 that displays selection icons 66A to 66C for selecting a user as shown in FIG. 15(b). The user names displayed on the selection icons 66A to 66C are the user names registered in the SFL database 19. When an arbitrary user name is selected from the selection icons 66A to 66C, the controller 11 displays a password input screen 67 as shown in FIG. 15(c), accepts the login password by the input key 68A, and displays it in the password display field 68B. When the OK button 68C is touched, the controller 11 changes the state to the login state when the user name selected on the user change screen 65 and the password input on the password input screen 67 match the data registered in the SFL database 19.

[0054] The example shown in FIG. 15 shows a screen in which "User A" is selected and the login authentication is successful. As shown in FIG. 15(d), the controller 11 displays the login user name in the information bar 62 on the standby screen 60A after login. For example, when the information bar 62 is touched, the controller 11 accepts a logout operation. For example, when the information bar 62 is touched, the controller 11 displays the user change screen 65 of FIG. 15(b), and when the selection icon 66A of "Public" is touched, the logout is executed and the standby screen 60 of FIG. 15(a) is displayed.

[0055] Further, the controller 11 can also accept an operation instruction to change the logged-in user via the user change screen 65 in FIG. 15(b). For example, in the standby screen 60A after login in FIG. 15(d), when the information column 62 is touched and the user change screen 65 is displayed, and then the selection icon 66B for "User A" or the selection icon 66C for "User B" is touched, the password input screen 67 shown in FIG. 15(c) is displayed to accept the input of the login password. If the input password matches the data registered in the SFL database 19, the system may transition to the logged-in state. That is, in the logged-in state, an operation to log in as another user may be accepted, and the logged-in user may be changed. Also, the controller 11 may be configured to display the logged-in user name instead of the tray icon 63 at the location of the tray icon 63 on the standby screen 60A. Then, when the logged-in user name is touched, the controller 11 may accept a logout operation. Further, when the information column 62 on the standby screen 60A in FIG. 15(d) is touched, the controller 11 may execute logout without displaying the user change screen 65 in FIG. 15(b).

[0056] In addition, when the scan icon 61C displayed on the logout standby screen 60 (Fig. 15(a)) or the login standby screen 60A (Fig. 15(d)) is operated, the controller 11 accepts an execution instruction for push scan. When the controller 11 accepts an execution instruction for push scan (S1: YES), after determining the feasibility of the above execution (S11), when starting the scan process (S29), it displays the scan in-progress screen 69 shown in Fig. 15(e). Also, when the controller 11 accepts an execution instruction for pull scan from the PC 40 (S1: YES), after determining the feasibility of the above execution (S12), when starting the scan process (S40) as well, it displays the scan in-progress screen 69 shown in Fig. 15(e). Further, when starting the scan process (S40), the controller 11, based on a predetermined condition (Fig. 11) described later, replaces the scan in-progress screen 69 with the scan in-progress screen 71 having a cancel button 73 shown in Fig. 15(f) and displays it. The controller 11 displays the file name to be created, etc. on the scan in-progress screens 69 and 71, but does not display the information column 62 for performing the logout operation (Fig. 15(e)(f)). When the scan process is completed (S3: YES), if in the login state, the controller 11 displays the standby screen 60A in Fig. 15(d), and if in the logout state, it displays the standby screen 60 in Fig. 15(a). Therefore, when starting the scan process in the login state, the controller 11 causes the scan in-progress screen 69 or the scan in-progress screen 71 to be displayed on the user IF 16 until the end of the scan process (S3: YES) or until cancel described later is executed (S9: YES), and prevents the execution of the logout operation or the change of the logged-in user. Executing cancel is also described as canceling. Note that the method of preventing the execution of the logout operation or the change operation of the logged-in user is not limited to the method of displaying the scan in-progress screen 69. For example, even after starting the scan process, the controller 11 may display the standby screens 60 and 60A and display the information column 62, but may disable the operation on the information column 62.Further, the controller 11 may be configured to accept a logout operation or a change operation of the logged-in user via the user IF 16 even after starting the scan process and until the scan process is terminated or canceled (during scanning).

[0057] Next, a process in which the controller 11 accepts an instruction to cancel a job (hereinafter sometimes referred to as a scan job) generated based on a scan execution instruction received from a user will be described. In the following description, to avoid complexity, the case where only one scan job is generated will be described. However, even when a plurality of scan jobs are generated, it is possible to determine whether to permit the execution of cancellation in the same manner as the cancellation process for one scan job described below.

[0058] As shown in FIG. 3, when the controller 11 executes the scan request process of S2, if the "push scan" started by S29 or the "pull scan" started by S40 is being continued in the scan request process of S2 (S3: NO), that is, if the output of the generated scan data is not completed, the process proceeds to S4. In S4, the controller 11 executes an error occurrence monitoring process. In addition, if the "push scan" or "pull scan" started by the scan request process of S2 is completed (S3: YES), that is, if the output of the generated scan data is completed, the process shown in FIG. 3 is completed. Also, if neither the "push scan" nor the "pull scan" is started by the scan request process of S2 (S3: YES), that is, if neither S29 nor S40 is executed, the process shown in FIG. 3 is completed.

[0059] As shown in FIG. 10, when starting the process of S4, the controller 11 determines whether an error has occurred in the MFP 10 (S80). The error that the controller 11 determines in S80 is, for example, an error that affects other processes by continuing the scan process or an error that makes it difficult to continue the scan process. Specifically, it is a state where the storage capacity of the memory 12 becomes insufficient (hereinafter sometimes referred to as memory full). As will be described later, the controller 11 continues to generate scan data based on the scan job until receiving an instruction to cancel the scan job in S6. When storing the generated scan data in the memory 12 until determining whether to permit the execution of the cancellation, depending on the capacity of the generated scan data and the size of the storage capacity of the memory 12, there may be a shortage of the working area in the memory 12 and the memory may become full. Also, even when receiving an instruction to cancel, if the output of the scan data is temporarily stopped and the generation of the scan data is continued and accumulated in the memory 12, the possibility of the memory becoming full further increases. When the memory becomes full, there may be a shortage of the working area for other processes, and there may be a delay or the like in the execution of other processes. For this reason, when the memory becomes full, the controller 11 determines that an error has occurred (S80: YES), and sets a value (true) indicating that an error has occurred in the error occurrence flag indicating the presence or absence of the occurrence of an error (S81). Also, when the controller 11 determines in S80 that no error has occurred (S80: NO), it sets a value (false) indicating that no error has occurred in the error occurrence flag (S82).

[0060] Note that the error to be determined in S80 is not limited to the above-described memory full. For example, when the MFP 10 is equipped with an ADF, the controller 11 may determine that an error has occurred when a paper jam occurs in the conveyance of the original to be scanned in the ADF. In this case, it becomes difficult to continue the scan process. Alternatively, when an error occurs in the operation of reading the original by the reading sensor, the controller 11 may similarly determine that an error has occurred because it is difficult to continue the scan process.

[0061] As shown in FIG. 3, when the controller 11 executes S4, it executes the panel display process of S5. As shown in FIG. 11, when the controller 11 starts the process of S5, it refers to the authentication completion flag (S91), and determines whether the value referred to is a value (true) indicating success, that is, whether the currently executing scan job is a pull scan that requires user authentication (S92).

[0062] When the function "SFL" is invalid (S51: NO in FIG. 7), or when the function "SFL" is valid (S51: YES) and there is no restriction on the function "scan" in "Public Mode" (S53: NO), a negative determination is made in S33 (S33: NO), S36 is not executed, and S62 and S63 in FIG. 8 are not executed. Also, in the case of push scan (S10: YES), S62 and S63 in FIG. 8 are not executed. Therefore, in the case of the above three examples, a value (true) indicating success is not set in the authentication completion flag. In this case, the controller 11 makes a negative determination in S92 (S92: NO), executes S97, and displays a scan execution screen 71 (FIG. 15(f)) including a cancel button 73 for instructing cancellation of the scan job on the touch panel 16A (see FIG. 1) of the user IF 16, and ends the process of FIG. 11. Therefore, when the function "SFL" is invalid, when the function "SFL" is valid and there is no restriction on the function "scan" in "Public Mode", or in the case of push scan, a software key for instructing cancellation is displayed on the touch panel 16A of the user IF 16.

[0063] On the one hand, when the function "SFL" is valid (S51: YES), the restriction of the function "scan" is set in "Public Mode" (S53: YES), and the user authentication information received together with the execution instruction of the pull scan is registered in the SFL database 19 and the user authentication is successful (S61: YES), the value of the authentication completion flag is set to a value (true) indicating success (S62). In this case, the controller 11 makes an affirmative determination in S92 (S92: YES) and executes S94. In S94, the controller 11 determines whether it is in the login state. When the MFP 10 is in the login state (S94: YES), the scan execution screen 71 (Fig. 15(f)) including the cancel button 73 is displayed on the touch panel 16A (S97), and the process of Fig. 11 ends. Therefore, even when the user authentication information received together with the execution instruction of the pull scan is registered in the SFL database 19 and the user authentication is successful, if it is in the login state, the cancel button 73 is displayed on the scan execution screen 71 (Fig. 15(f)), and an instruction to cancel the operation of the cancel button 73 can be received.

[0064] Also, when the value of the authentication completion flag is set to a value (true) indicating success (S92: YES) and the MFP 10 is in the logout state (S94: NO), the controller 11 proceeds to S95. Hereinafter, the processes of S95 to S96 will be described for three cases. Note that the controller 11 refers to the error occurrence flag (S95) and determines whether the value of the error occurrence flag is a value (true) indicating that an error has occurred, that is, whether an error has occurred (S96).

[0065] (1) When the scan is disclosed, the value of the authentication completion flag is set to a value indicating success (true) (S92: YES), and the case where the MFP 10 is in the logout state (S94: NO) will be described. At the start of the scan, of course, no error has occurred. The controller 11 makes a negative determination in S96 (S96: NO), displays the scan execution screen 69, that is, displays the scan execution screen 69 without the cancel button 73 (S98), and ends the process of FIG. 11. As shown in FIG. 3, the controller 11 repeats S5 when the scan is not completed (S3: NO) and, as described later, when no cancel instruction is received (S6: NO), or when the scan is not completed (S3: NO) and, as described later, the scan job is not canceled (S9: NO). The determination result of S92 remains unchanged (S92: YES), and the logout state is maintained during the scan execution (S94: NO). Therefore, if no error occurs, the controller 11 makes a negative determination in S96 (S96: NO) and continues to display the scan execution screen 69 (S98).

[0066] Next, the case where an error occurs after the scanning execution screen 69 is displayed at the start of (2) scanning will be described. For example, when an error occurs while the scanning execution screen 69 is being displayed by executing the process of (1) above, the controller 11 executes S5, and the determination result of S92 remains unchanged (S92: YES). The logout state is maintained during the scan execution (S94: NO), and an affirmative determination is made in S96 (S96: YES). The controller 11 displays the cancel button 73 on the scanning execution screen 69, that is, switches to the display of the scanning execution screen 71 (S97). As described above, when the scan is not completed (S3: NO) and no cancel instruction is received (S6: NO), or when the scan is not completed (S3: NO) and the scan job is not canceled (S9: NO), the determination result of S92 remains unchanged (S92: YES), and the logout state is maintained during the scan execution (S94: NO). Therefore, if the error that has occurred is not cleared, the controller 11 makes an affirmative determination in S96 (S96: YES) and continues to display the scanning execution screen 71 (S97). Further, after the controller 11 displays the scanning execution screen 71, if the error is cleared, a negative determination is made in S96 (S96: NO), and the cancel button 73 is deleted from the scanning execution screen 71, that is, the display is switched to the scanning execution screen 69 (S98). Further, after the controller 11 switches to the display of the scanning execution screen 69, if an error occurs again, an affirmative determination is made in S96 (S96: YES), and the cancel button 73 is displayed on the scanning execution screen 69, that is, the display is switched to the scanning execution screen 71 (S97).

[0067] Next, after displaying the scanning-in-progress screen 71 at the start of (3) scanning, the case where an error occurs will be described. If an error occurs while the scanning-in-progress screen 71 is being displayed at the start of scanning, the controller 11 executes S5, and the determination results of S92 and S94 do not change. That is, S92: NO, or S92: YES and S94: YES. Therefore, if the scanning is not completed and the error is not cleared, the controller 11 continues to display the scanning-in-progress screen 71.

[0068] As shown in FIG. 3, when the controller 11 executes S5, at S6, it determines whether an instruction to cancel the scan job (hereinafter sometimes referred to as a cancel instruction) has been received. As a method for the user to execute the cancel instruction for the scan job, there are a method of operating the user IF 16 of the MFP 10 to execute the cancel instruction (hereinafter referred to as a cancel instruction by user IF operation) and a method of operating the PC 40 to execute the cancel instruction (hereinafter referred to as a cancel instruction by PC operation). The cancel instruction by user IF operation is a cancel instruction by operating the cancel button 73 included in the scanning-in-progress screen 71. Alternatively, the cancel instruction by user IF operation is a cancel instruction by operating the cancel key 16B provided separately from the touch panel 16A. Note that when it is possible to receive the cancel instruction by operating the cancel button 73, it is when the scanning-in-progress screen 71 is being displayed. Therefore, the controller 11 can receive the cancel instruction by user IF operation by operating the cancel key 16B (hardware key) or the cancel button 73 (software key) displayed on the touch panel 16A. If the controller 11 does not receive the cancel instruction (S6: NO), it returns to S3. As described above, when "push scan" or "pull scan" is being continued (S3: NO), that is, when the output of the generated scan data is not completed, it proceeds to S4.

[0069] When the controller 11 receives a cancel instruction (S6: YES), in S7, it executes job cancellation request processing. Note that when the controller 11 makes an affirmative determination in S6 (S6: YES), it temporarily stops the output of scan data. The controller 11 also temporarily stops, for example, the generation of scan data and the reading of the original by the scanner 15. Also, the controller 11 may not stop the reading of the original by the scanner 15 and the generation of scan data, and may temporarily stop the output of scan data. In this case, the controller 11 may temporarily store the generated scan data in the memory 12. Further, as shown in FIG. 12, when the controller 11 starts the processing of S7, it checks the type of the scan job (S101). First, the processing when a cancel instruction is executed after the push scan is started will be described. In this example, when the controller 11 determines that the type of the scan job is not a pull scan, that is, it is a push scan job (S102: NO), it executes the job cancellation processing of S104. Note that when the type of the scan job confirmed by the controller 11 in S101 is a pull scan (S102: YES), it executes the job cancellation processing of the pull scan of S103, which will be described later.

[0070] As shown in FIG. 13, when the controller 11 starts the process of S104, it cancels the currently executing scan job. In this example, the controller 11 cancels the scan job of push scan (S105). The processing such as the output of scan data, which had been temporarily stopped, is completely terminated. If there is generated scan data, it is discarded. When the controller 11 executes S105, it ends the process of FIG. 12. As shown in FIG. 3, after executing S7, the controller 11 determines whether the scan job has been canceled, that is, whether S105 in FIG. 13 has been executed (S9). When the controller 11 has canceled the scan job (S9: YES), it ends the process shown in FIG. 3. The controller 11 ends the display of the scan execution screen 71 (FIG. 15(f)), and if it is in the logged-in state, it displays the standby screen 60A (FIG. 15(d)), and if it is in the logged-out state, it displays the standby screen 60 (FIG. 15(a)). Also, in each example described below, in response to the cancellation of the scan job (S9: YES), the display of the scan execution screen 69 or the scan execution screen 71 is ended, and if it is in the logged-in state, the standby screen 60A (FIG. 15(d)) is displayed, and if it is in the logged-out state, the standby screen 60 (FIG. 15(a)) is displayed. Further, when the controller 11 makes an affirmative determination in S6, it may execute the processes of FIGS. 12 and 13 without temporarily stopping the execution of the scan job (output of scan data, etc.).

[0071] Therefore, in the case of push scan, cancellation is executed regardless of whether the cancellation is indicated by the cancellation key 16B for user IF operation, the cancellation button 73, or the cancellation instruction by PC operation. As described above, in the case of push scan, an operation by the user IF 16 of the MFP 10 is required when instructing the start of scanning. For this reason, when a cancellation instruction is given by a user IF operation, it is highly likely that the user who instructed push scan in front of the user IF 16 gave the cancellation instruction by operating the user IF 16 again. Also, the means for receiving a cancellation instruction for a scan job is basically provided only outside the devices related to that scan job. Specifically, means for receiving a cancellation instruction for a scan job is not provided outside the device that receives an instruction to start scanning and the device that executes the scan job based on the received instruction. That is, basically, a cancellation instruction is not given from another device that has nothing to do with the execution of the scan job. In the case of push scan, both the device that receives an instruction to start scanning and the device that executes the scan job are the MFP 10. Therefore, it is appropriate to provide the means for receiving a cancellation instruction for a scan job only in the MFP 10. Therefore, for push scan, regardless of the login state, logout state, etc., when a cancellation instruction is received, cancellation is executed without confirming the login state (S113) or the occurrence of an error (S115) described later. Also, by displaying the cancellation button 73, a cancellation instruction can be received by a software key as well.

[0072] Next, the processing when a cancellation instruction by PC operation is given after pull scan is started will be described. In this example, when the controller 11 makes an affirmative determination in S102 of FIG. 12 (S102: YES) and starts the processing of S103 shown in FIG. 14, the controller 11 confirms the request source of the job cancellation, that is, confirms the method by which the cancellation instruction was issued (S110). If the cancellation instruction is not a cancellation instruction by PC operation, that is, if the cancellation instruction is a cancellation instruction by user IF operation (S111: NO), the controller 11 executes S112.

[0073] In this example, since the cancel instruction is a cancel instruction by PC operation (S111: YES), the controller 11 executes the job cancel process shown in FIG. 13 (S116). In the case of pull scan, the device that receives the instruction to start the scan is the PC 40. Therefore, in this embodiment, for pull scan, except for the MFP 10, the cancel instruction for the scan job based on the instruction is received only from the PC 40 that has received the instruction to start the scan. Therefore, when the pull scan is executed, the cancel instruction by PC operation can be transmitted only from the same PC 40 (external device). In other words, a pull scan instructed by an arbitrary user on the PC 40 cannot be canceled by another user operating another PC. Therefore, even when a cancel instruction by PC operation is given, it is highly likely that the user who instructed the pull scan executed the cancel instruction from the same PC 40. For this reason, also for the cancel instruction by PC operation for the pull scan, the scan job is canceled (S105) without checking the login state (S113) or the occurrence of an error (S115).

[0074] Next, when the function "SFL" is invalid (S51: NO in FIG. 7), or when the function "SFL" is valid (S51: YES) and there is no restriction on the function "scan" in "Public Mode" (S53: NO), the process when a pull scan is executed and a cancel instruction is given by user IF operation will be described. In this case, as described above, the value (true) indicating success is not set in the authentication completion flag.

[0075] The controller 11 makes an affirmative determination in S6 of FIG. 3 (S6: YES), makes an affirmative determination in S102 of FIG. 12 (S102: YES), makes a negative determination in S111 of FIG. 14 (S111: NO), executes S112, and since, similar to S92, a value (true) indicating success is not set in the authentication completion flag (S112: NO), it executes job cancellation processing (S116). Therefore, in the cases of the above two examples, when a cancellation instruction is given by a user IF operation targeting a pull scan, without checking the login state (S113) or occurrence of an error (S115) described later, it executes cancellation of the scan job (S105). Also, it accepts a cancellation instruction by the cancel button 73 displayed on the scan execution screen 71 (S92: NO).

[0076] Next, for the pull scan (hereinafter referred to as the authenticated pull scan) when the function "SFL" is enabled (S51: YES), the restriction of the function "scan" is set in "Public Mode" (S53: YES), and the user authentication information received together with the execution instruction of the pull scan is registered in the SFL database 19 and the user authentication is successful (S61: YES). First, after the authenticated pull scan is started, the processing when a cancel instruction is given by the user IF operation in the logged-in state will be described. In this example, the controller 11 makes an affirmative determination at S6 in FIG. 3 (S6: YES), makes an affirmative determination at S102 in FIG. 12 (S102: YES), makes a negative determination at S111 in FIG. 14 (S111: NO), and executes S112. In this example, since the value of the authentication completion flag is set to a value indicating success (true), the controller 11 makes an affirmative determination at S112 (S112: YES), and at S113, determines whether it is in the logged-in state. In this example, since it is in the logged-in state (S113: YES), job cancellation processing is executed (S116). Therefore, when a cancel instruction is given by the user IF operation for the authenticated pull scan in the logged-in state, the scan job is cancelled (S105) without confirming the occurrence of an error (S115) described later. Also, a cancel instruction is not received by the cancel button 73 displayed on the scan execution screen 71 (S92: NO). Note that the controller 11 may make the cancel button 73 non-displayed and not receive a cancel instruction when a cancel instruction is given by the user IF operation for the authenticated pull scan in the logged-in state.

[0077] Next, after an authenticated pull scan is started, the processing when an error occurs in the logged-out state and a cancel instruction is given by a user IF operation will be described. In this example, the controller 11 executes the same processing as in the above example, makes an affirmative determination in S112 of FIG. 14 (S11: YES), makes a negative determination in S113 (S113: NO), and executes S114. The controller 11 refers to the error occurrence flag in S114 and determines whether an error has occurred based on the error occurrence flag (S115). In this example, since an error has occurred (S115: YES), job cancellation processing is executed (S116). Therefore, when a cancel instruction is given by a user IF operation for an authenticated pull scan in the logged-out state and an error occurs, the scan job is canceled (S105). Also, a cancel instruction is accepted by the cancel button 73 displayed on the scan execution screen 71 (S96: YES). Note that the controller 11 may be configured to immediately end the scan job when an event that requires immediate termination of the scan job, such as a critical error, occurs.

[0078] Next, after an authenticated pull scan is started, the processing when an error does not occur in the logged-out state and a cancel instruction is given by a user IF operation will be described. In this example, the controller 11 processes up to S115 in the same manner as when the above error occurred (S6: YES, S102: YES, S111: NO, S112: YES, S113: NO). In this example, since no error has occurred (S115: NO), S117 is executed.

[0079] The controller 11 continues to execute the scan job by the scanner 15 without canceling the scan job (S117). The controller 11 resumes the output of scan data and the like that had been temporarily stopped, and ends the process shown in FIG. 14. Also, the controller 11 ends the process of FIG. 12. As shown in FIG. 3, after executing S7, the controller 11 executes S9. If the scan job is not canceled (S9: NO), that is, if S117 is executed, the process from S3 is executed again. The scan job of the pull scan continues without being canceled. Therefore, as described above, for an authenticated pull scan, when in the logged-out state (S94: NO) and no error has occurred (S96: NO), the cancel button 73 is made non-displayable and no cancel instruction by the software key is accepted. Also, even if the cancel key 16B of the hardware key is operated, no cancel is executed as long as no error has occurred (S115: NO).

[0080] Also, without canceling (S9: NO), if there is no cancel instruction for the scan job during the continued scan, the controller 11 completes the scan (S3: YES). When a cancel instruction is received again (S6: YES), it is determined again whether to permit the execution of the cancel (S7). Also, the process from S3 is executed again. If the scan is not completed (S3: NO), S4 is executed, it is determined that an error has occurred, S5 is executed, and the display / non-display of the cancel button 73 is changed. Note that the controller 11 does not necessarily have to temporarily stop the execution of the scan job when a positive determination is made in S6. In this case, the process of S105 can be omitted.

[0081] While the scan is in progress, the scanning-in-progress screen 69 or the scanning-in-progress screen 71 is being displayed. Therefore, when the pull scan is requested while the MFP 10 is in the logged-out state and the pull scan is started after successful authentication of the user who requested the pull scan, the user cannot operate the standby screen 60 in Fig. 15(a) to log in. Also, when the pull scan is requested while the MFP 10 is in the logged-in state and the pull scan is started after successful authentication of the user who requested the pull scan, the user cannot operate the standby screen 60A in Fig. 15(d) to log out or to change the logged-in user. Accordingly, while the pull scan is in progress, by displaying the scanning-in-progress screen 69 or the scanning-in-progress screen 71, it is restricted that a user other than the user who gave the start instruction operation for the pull scan logs out the MFP 10 or makes it a new logged-in state via the standby screen 60 or the standby screen 60A in order to operate the MFP 10.

[0082] In the present embodiment described above, the following effects can be achieved. When the controller 11 of the MFP 10 receives user authentication information together with an execution instruction for the pull scan (S92: YES), the controller 11 causes the scanning-in-progress screen 69 that does not include the cancel button 73 to be displayed on the touch panel 16A (S98). Also, when the controller 11 has not received user authentication information together with the execution instruction for the pull scan (S92: NO), the controller 11 causes the scanning-in-progress screen 71 that includes the cancel button 73 to be displayed on the touch panel 16A, and cancels the pull scan in progress in response to receiving an operation on the cancel button 73 (S112: NO, S116). Note that the case where user authentication information has not been received may include not only the case where user authentication information is not transmitted from the PC 40 because it is not requested from the MFP 10, but also the case where the controller 11 does not accept the user authentication information (user name and password) transmitted from the PC 40 even though it is not requested from the MFP 10.

[0083] Also, when the controller 11 receives user authentication information together with an execution instruction for a pulse scan regarding the operation of the cancel key 16B (S112: YES), even if the cancel key 16B is operated during the execution of the pulse scan, the controller 11 does not cancel the pulse scan. On the other hand, when this is not the case (S112: NO), the controller 11 cancels the pulse scan (S116) in response to the operation of the cancel key 16B.

[0084] Accordingly, when receiving user authentication information together with an execution instruction for a pulse scan, by making the cancel button 73 non-displayable, it is possible to prohibit a user other than the user indicated by the user authentication information from canceling the pulse scan. Also, by not allowing a cancel instruction by the cancel key 16B, it is possible to prohibit a user other than the user indicated by the user authentication information from canceling the pulse scan. Further, when not receiving user authentication information together with an execution instruction for a pulse scan, the pulse scan can be canceled by displaying the cancel button 73. Also, the pulse scan can be canceled by operating the cancel key 16B. For a scan job without user authentication information, a cancel instruction can be permitted by a user operation.

[0085] Also, when the controller 11 is in a logged-in state and receives an execution instruction for a pulse scan together with user authentication information, if the user authentication information of the logged-in user corresponds to the user authentication information received together with the execution instruction for the pulse scan (S72: NO), the controller 11 starts the pulse scan (S76), and if not, does not start it (S72: YES, S73). If the controller 11 starts the pulse scan because the user authentication information of the logged-in user corresponds to the user authentication information received together with the execution instruction for the pulse scan, even when receiving user authentication information together with the execution instruction for the pulse scan, the controller 11 displays the cancel button 73 (S94: YES), accepts a cancel instruction by operating the cancel button 73, and cancels it (S113: YES, S116). Also, the controller 11 cancels it even when the cancel key 16B is operated (S113: YES, S116).

[0086] Accordingly, even when receiving user authentication information, if in the logged-in state, a cancel instruction by the cancel button 73 or the cancel key 16B is accepted and canceled. As described above, when the controller 11 starts the scan process in the logged-in state, until the end of the scan process or the cancellation is executed, the in-scan screen 69 or the in-scan screen 71 is displayed on the user IF 16, and operations such as a logout operation or an operation to change the logged-in user cannot be executed. Another user other than the logged-in user cannot log in or switch the logged-in user. For this reason, if in the logged-in state before the start of the pull scan, the user who logged in by operating the user IF 16 becomes the user who requested the pull scan (S72: NO). Therefore, when the pull scan is started in the logged-in state, the cancel button 73 is displayed on the in-scan screen 71 (S94: YES), and a cancel instruction by the cancel button 73 is accepted and canceled (S113: YES, S116). Also, the controller 11 cancels when the cancel key 16B is operated (S113: YES, S116). Accordingly, if in the logged-in state, by permitting a cancel instruction by operating the user IF, an appropriate user can be made to execute the cancellation.

[0087] Also, after the controller starts the pull scan because the user authentication information of the logged-in user corresponds to the user authentication information received together with the execution instruction of the pull scan (S72: NO), it displays the scan execution screen 69 or the scan execution screen 71, and until the pull scan is terminated or canceled, it does not accept an operation to change the logged-in user via the touch panel 16A and an operation to log out. Thereby, by not allowing the logged-in user to be changed, it is possible to restrict other users from executing a scan or the like during the pull scan. Also, if the system shifts to the logged-out state, there is a risk that the user who requested the pull scan will not be able to cancel it (S94: NO, S113: NO). Therefore, by prohibiting the logout operation, the user who requested the pull scan can secure a means to give a cancel instruction. Note that the controller 11 may be configured not to accept at least one of the operation to change the logged-in user via the touch panel 16A and the operation to log out until the pull scan is terminated or canceled.

[0088] Also, in the logged-out state, in response to receiving an execution instruction of the pull scan together with user authentication information, after the controller 11 starts the pull scan (S70: NO), it displays the scan execution screen 69 or the scan execution screen 71, and until the pull scan is terminated or canceled, it does not accept a login operation via the touch panel 16A. Thereby, in the case of the logged-out state, by not allowing a transition to the logged-in state, it is possible to prohibit other users other than the user who requested the pull scan from logging in and giving a cancel instruction.

[0089] Further, the controller 11 determines whether an error has occurred in the MFP 10 (S4, S80). Even when the controller 11 has received user authentication information together with an instruction to start the pull scan after starting the pull scan (S92: YES), if an error has occurred (S96: YES), the cancel button 73 is displayed (S97). Further, in response to receiving an operation on the displayed cancel button 73, the controller 11 cancels the ongoing pull scan (S115: YES). Also, even when the controller 11 has received user authentication information together with an instruction to execute the pull scan, if an error has occurred, in response to the cancel key 16B being operated, the controller 11 cancels the pull scan (S115: YES).

[0090] Thereby, a means for quickly terminating a scan job in which an error has occurred can be provided to the user. If an error such as out-of-memory occurs after starting the pull scan, by permitting cancellation by the cancel button 73 or the cancel key 16B, it is possible to suppress the continued execution of the pull scan in a state where an error has occurred. It is possible to suppress the transmission of scan data in which a read error has occurred. In other words, even if an error occurs, the scan job can be continued as much as possible, such as continuing to transmit the scan data that has been created until the user gives a cancellation instruction. In the case where, for example, a paper jam in the ADF is regarded as an error occurrence, the user can select whether to give a cancellation instruction or to remove the event that causes the error and continue the scan job, for example, by removing the paper jam in the ADF.

[0091] Also, after starting the push scan, the controller 11 displays the cancel button 73 (S92: NO, S97), accepts a cancel instruction by the cancel button 73, and cancels it (S112: NO, S116). Further, after starting the push scan, the controller 11 also accepts a cancel instruction by the cancel key 16B and cancels it (S112: NO, S116). In the push scan operation, since an operation by the user IF16 is required, it is highly likely that the user who operates the user IF16 to give a cancel instruction is the user who instructed the execution of the push scan. Therefore, for the push scan, by permitting a cancel instruction by the cancel button 73 or the cancel key 16B, an appropriate user can be made to execute the cancel.

[0092] Also, when the controller 11 accepts a cancel instruction by a PC operation (S111: YES), even if it has received user authentication information together with an execution instruction for the pull scan, it cancels the ongoing pull scan (S116). When the controller 11 starts the pull scan, it does not accept a cancel instruction for the started pull scan from outside the instructing source PC40. In other words, when a cancel instruction is accepted after the start of the pull scan, it means that the cancel instruction has been accepted from the same PC40 as the PC40 that gave the execution instruction. Therefore, in this case, by permitting the cancel, an appropriate user can be made to execute the cancel instruction.

[0093] (Modification of the Embodiment) In the above-described embodiment, if the restriction setting value "restriction" is registered in the SFL database 19 for the function "scan" in "Public Mode", that is, the push scan in the logged-out state (S53: YES), the controller 11 requires user authentication in the pull scan. Instead of this, if the restriction setting value "restriction" is registered in the SFL database 19 referred to in S52 for the function "scan" corresponding to all registered users (S53: YES), the controller 11 may require user authentication in the pull scan. Furthermore, if the restriction setting value "restriction" is registered in the SFL database 19 referred to in S52 for the function "scan" by a predetermined specific user (S53: YES), the controller 11 may require user authentication in the pull scan.

[0094] The controller 11 may execute the user authentication process in S36 of FIG. 6 and the scan permission confirmation process in S38 as follows. In this example, in the user authentication process executed in S36, it is determined whether the user operating the PC 40 matches the user logged in to the MFP 10 (the processes in S70 to S72 of FIG. 9). First, in the user authentication process executed by the controller 11 in S36, at S60, the controller 11 checks whether the user authentication information received from the PC 40 is registered in the memory 12 as an authentication target. If the user authentication information is registered as an authentication target (S61: YES), at S70 described in FIG. 9, the controller 11 determines whether the MFP 10 has already been logged in. If the MFP 10 has already been logged in (S70: YES), the process proceeds to S71, and the controller 11 determines whether the user who requested the pull scan matches the logged-in user. If the controller 11 determines that the users match (S72: YES), the process proceeds to S62 (FIG. 8), where a flag indicating that the user authentication has succeeded is set, and the process proceeds to S37. Even if the controller 11 determines that the user has not logged in (S70: NO), the process proceeds to S62, where a value indicating that the user authentication has succeeded is set in the authentication completion flag, and the process proceeds to S37. On the other hand, if the controller 11 determines that the users do not match (S72: NO), the process proceeds to S63, where a value indicating that the user authentication has failed is set in the authentication completion flag, and the process proceeds to S37.

[0095] When the controller 11 determines in S37 of FIG. 6 that the user authentication has succeeded (S37: YES), it proceeds to S38 and performs the scan permission confirmation process. In the scan permission confirmation process performed in S38, the processes of S70 to S72 that have already been executed in the user authentication process in S36 are not executed. Specifically, in S74, the controller 11 refers to the limit setting value of the function "scan process" corresponding to the user who has successfully authenticated. In S75, if the limit setting value "restriction" is registered in the SFL database 19 for the function "scan" of the user who has successfully authenticated (S75: YES), the controller 11 proceeds to S73 and does not permit the start of the scan process (pull scan). On the other hand, if the limit setting value "permission" is registered in the SFL database 19 for the function "scan" of the user who has successfully authenticated (S75: NO), the controller 11 proceeds to S76 and permits the start of the pull scan.

[0096] (Other Embodiments) The reading device is not limited to the above-described embodiments, and various modifications are possible without departing from the spirit thereof. The order, content, etc. of the processes shown in FIGS. 3 to 14 in the above-described embodiments are examples. For example, in the above-described embodiments, the controller 11 confirms the registration of the pull scan user in S36 (S61), determines in S71 and S72 whether the registered user matches the logged-in user, and if they match (S72: NO), permits the execution of the pull scan. However, the controller 11 may only confirm the registration of the user in S36 (S61) and not determine the match with the logged-in user in S71 and S72. In this case, if the pull scan user is registered (S37: YES), the controller 11 may permit the execution of the pull scan regardless of the match with the logged-in user. In this case, when the function "SFL" is invalid, or when the function "SFL" is valid and in the "Public Mode" state, if a pull scan execution instruction is received and the user name received together with the instruction is registered in the SFL database 19, the execution of the pull scan may be permitted. Also, after starting the push scan in the logged-in state, if the controller 11 receives a cancel instruction while remaining in the logged-in state, it may again request the input of the password of the logged-in user, and cancel the push scan when the input password matches the input of the password of the logged-in user. Also, a configuration that does not execute a process or the like (S4, FIG. 10, S94) for determining whether an error has occurred in the MFP 10 may be used. In this case, when the controller 11 makes a negative determination in S3 of FIG. 3 (S3: NO), subsequently, in S5, the controller 11 will execute the panel display process. Also, when the controller 11 makes a negative determination in S94 of FIG. 11 (S94: NO), the controller 11 will execute S98. Also, when the controller 11 makes a negative determination in S113 of FIG. 14 (S113: NO), the controller 11 will execute S117.

[0097] In the above-described embodiment, the controller 11 uses the SFL database 19 to execute authentication of the user name and password and restriction of functions. However, authentication and function restriction may be executed using other information. For example, "Active Directory Authentication" or "LDAP Authentication" may be used. For example, when using "Active Directory Authentication", the controller 11 may perform login authentication to the MFP 10 based on the authentication information stored in the Active Directory (registered trademark) server. Further, the controller 11 may execute restrictions on functions such as the scan function using the restriction setting values for each user stored in the Active Directory server. Also, when using "LDAP Authentication", the controller 11 may perform login authentication to the MFP 10 based on the authentication information stored in the LDAP (abbreviation for Lightweight Directory Access Protocol) server. Further, the controller 11 may execute function restrictions using the restriction setting values stored in the LDAP server. Also, the above-described authentication and restriction methods may be used in combination or switched. Also, the authentication information and the restriction setting values may be stored in different storage units. For example, the controller 11 may perform login authentication to the MFP 10 based on the authentication information stored in the server and store the restriction setting values in the SFL database 19 of the memory 12.

[0098] In the above-described embodiment, the restriction setting values for the "SFL" function are set using the web page (home screen 20) transmitted from the controller 11 of the MFP 10. Instead of this, the restriction setting values for the "SFL" function may be set by operating the user interface 16 of the MFP 10. Therefore, the controller 11 may accept changes in the restriction values and the like in the same manner as the web page in response to operations on the user interface 16. The limit values in the SFL database 19 were applied to both push scans and pull scans. However, check items may be provided for each of the push scan and the pull scan to separately accept the presence or absence of restrictions. As an example of a reading device, the MFP10 was described as an example, but the reading device may be a device capable of executing only the function "scanner".

Explanation of symbols

[0099] 10…MFC (reading device), 11…controller, 15…scanner, 16…user IF, 16A touch panel, 16B cancel key, 19…SFL database, 40…PC, 69 scanning in progress screen, 71 scanning in progress screen, 73 cancel button.

Claims

1. A touch panel, a scanner, and a controller, wherein the controller is capable of executing a pull scan for causing the scanner to read a document according to an execution instruction from an external device, and the controller is configured to start the pull scan and display a scanning-in-progress screen on the touch panel in response to receiving the execution instruction for the pull scan, and the controller is configured to, when receiving user authentication information together with the execution instruction for the pull scan, display on the touch panel the scanning-in-progress screen without a cancel button, and the controller is configured to, when not receiving the user authentication information together with the execution instruction for the pull scan, display on the touch panel the scanning-in-progress screen including the cancel button, and cancel the in-execution pull scan in response to receiving an operation on the cancel button. A reading device configured as such.

2. The controller is configured to, in a logged-in state, start the pull scan if the user authentication information of the logged-in user corresponds to the user authentication information received together with the execution instruction for the pull scan, and not start it if it does not correspond, and the controller is configured to, if starting the pull scan because the user authentication information of the logged-in user corresponds to the user authentication information received together with the execution instruction for the pull scan, display on the touch panel the scanning-in-progress screen including the cancel button even when receiving the user authentication information together with the execution instruction for the pull scan, and cancel the in-execution pull scan in response to receiving an operation on the cancel button. The reading device according to Claim 1, configured as such.

3. The controller is configured not to receive at least one of an operation for changing the logged-in user and an operation for logging out via the touch panel until ending or canceling the pull scan after starting the pull scan because the user authentication information of the logged-in user corresponds to the user authentication information received together with the execution instruction for the pull scan. The reading device according to Claim 2, configured as such.

4. The controller is configured such that: in a state where no user is logged in, in response to receiving an execution instruction for the pull scan together with user authentication information, after starting the pull scan, until the pull scan is terminated or canceled, the controller does not accept a login operation via the touch panel. The reading device according to claim 2 **Claim 5** The controller is configured such that: it can determine whether an error has occurred in the reading device; The controller is configured such that: after starting the pull scan, if it is determined that an error has occurred in the reading device, even if it has received the user authentication information together with the execution instruction for the pull scan, the controller causes the touch panel to display the scan-in-progress screen including the cancel button, and in response to receiving an operation on the cancel button, cancels the ongoing pull scan. The reading device according to claim 1 or claim 2 **Claim 6** The controller is configured such that: it can execute a push scan for causing the scanner to read a document according to an execution instruction corresponding to an operation on the touch panel; The controller is configured such that: in response to receiving an execution instruction for the push scan via the touch panel, the controller starts the push scan and causes the touch panel to display a scan-in-progress screen; The controller is configured such that: after starting the push scan, the controller causes the touch panel to display the scan-in-progress screen including the cancel button, and in response to receiving an operation on the cancel button, cancels the ongoing push scan. The reading device according to claim 1 or claim 2 **Claim 7** The controller is configured such that: it can also receive a cancel instruction for the pull scan from the source that sent the execution instruction for the pull scan; The controller is configured such that: even if it has received the user authentication information together with the execution instruction for the pull scan, in response to receiving a cancel instruction for the pull scan from the source that sent the execution instruction for the pull scan, the controller cancels the ongoing pull scan. The reading device according to claim 1 or claim 2 **Claim 8** a display; hardware keys; a scanner; a controller; and is provided with: The controller is configured to: Execute a pull scan that causes the scanner to read a document according to an execution instruction from an external device; The controller is configured to: Start the pull scan and display a scanning-in-progress screen on the display in response to receiving the execution instruction for the pull scan. The controller is configured to: When receiving user authentication information together with the execution instruction for the pull scan, even if a cancel operation is performed on the hardware key during the execution of the pull scan, the controller does not cancel the pull scan being executed. When not receiving the user authentication information together with the execution instruction for the pull scan, the controller is configured to cancel the pull scan being executed in response to a cancel operation being performed on the hardware key during the execution of the pull scan. A reading device configured as such. **Claim 9** The controller is configured to: When logged in and receiving the execution instruction for the pull scan together with the user authentication information, if the user authentication information of the logged-in user corresponds to the user authentication information received together with the execution instruction for the pull scan, start the pull scan; otherwise, do not start the pull scan. The controller is configured to: If the pull scan is started because the user authentication information of the logged-in user corresponds to the user authentication information received together with the execution instruction for the pull scan, even when receiving the user authentication information together with the execution instruction for the pull scan, the controller is configured to cancel the pull scan being executed in response to a cancel operation being performed on the hardware key during the execution of the pull scan. The reading device according to Claim 8, configured as such. **Claim 10** Equipped with a touch panel, The controller is configured to: After starting the pull scan because the user authentication information of the logged-in user corresponds to the user authentication information received together with the execution instruction for the pull scan, until the pull scan is ended or canceled, not accept at least one of the operations of changing the logged-in user and logging out via the touch panel. The reading device according to Claim 9, configured as such. **Claim 11** Equipped with a touch panel, The controller is configured to: After receiving an execution instruction for the pull scan together with user authentication information in a non-logged-in state, after starting the pull scan, until the pull scan is terminated or canceled, the touch panel is configured not to accept a login operation. The reading device according to claim 9.

12. The controller is configured to be able to determine whether an error has occurred in the reading device, The controller is after starting the pull scan, if it is determined that an error has occurred in the reading device, even if the user authentication information is received together with the execution instruction for the pull scan, during the execution of the pull scan, in response to a cancel operation being performed on the hardware key, the pull scan being executed is canceled. The reading device according to claim 8 or claim 9.

13. equipped with a touch panel, The controller is able to execute a push scan for causing the scanner to read a document according to an execution instruction corresponding to an operation on the touch panel, The controller is configured to start the push scan in response to receiving an execution instruction for the push scan via the touch panel and display a scanning-in-progress screen on the touch panel, The controller is configured to cancel the push scan being executed in response to a cancel operation being performed on the hardware key during the execution of the push scan after starting the push scan. The reading device according to claim 8 or claim 9.

14. The controller is also configured to be able to receive a cancel instruction for the pull scan from the source that sent the execution instruction for the pull scan, The controller is configured to cancel the pull scan being executed in response to receiving a cancel instruction for the pull scan from the source that sent the execution instruction for the pull scan, even if the user authentication information is received together with the execution instruction for the pull scan. The reading device according to claim 8 or claim 9.

Images