Reading device

Abstract

To provide a reading device that can make an appropriate user execute the cancellation of scanning.SOLUTION: After starting a pull scan, when a cancel instruction is received via user IF 16 to cancel a scan job, a controller 11 of an MFP 10 receives user authentication information via the user IF 16 (S134). If the received user authentication information matches user authentication information received together with a pull scan execution instruction (S136: YES), the controller 11 cancels the pull scan (S137), and if they do not match, the controller 11 does not cancel it (S136: NO). This allows the pull scan to be cancelled if a user who instructed the execution of the pull scan cancels it via the user IF 16.SELECTED DRAWING: Figure 17

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 pulse scan for causing 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 pulse scan is registered, and when an execution instruction for the pulse 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 pulse scan.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In a scan 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 from the viewpoint 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 a scan.

Means for Solving the Problems

[0006] To solve the above problems, the reading device disclosed in this embodiment includes a user interface, a scanner, and a controller. The controller can execute a pull scan to cause the scanner to read a document according to an execution instruction from an external device. The controller can start the pull scan in response to receiving the execution instruction for the pull scan together with user authentication information. After starting the pull scan, when receiving a cancel instruction via the user interface, the controller receives user authentication information via the user interface. If the user authentication information received via the user interface corresponds to the user authentication information received together with the execution instruction for the pull scan, the controller cancels the pull scan; if not, the controller does not cancel the pull scan.

[0007] In the above configuration, after starting the pull scan, when receiving a cancel instruction via the user interface, the controller receives user authentication information. If the received user authentication information corresponds to the user authentication information received together with the execution instruction for the pull scan, the controller cancels the pull scan; if not, the controller does not cancel the pull scan. Thereby, when the user who instructed the execution of the pull scan instructs cancellation via the user interface, cancellation can be permitted, and when another user instructs cancellation, cancellation can be prevented.

Advantages of the Invention

[0008] According to the present invention, an appropriate user can be made to execute the cancellation of scanning.

Brief Description of the Drawings

[0009]

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

Figure 16

Figure 17

Figure 18

Embodiments for Carrying Out the Invention

[0010] Embodiments of a 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 FAXIF 14, a scanner 15, a user IF 16, a USBIF 17, and a communication IF 18. These components are communicably connected to each other via a bus 1.

[0011] 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.

[0012] The user IF 16 is an interface capable of receiving various operations on the MFP 10. The user IF 16 includes a touch panel including a liquid crystal display and various operation keys. The various operation keys include a cancel key to be described later. The cancel key is a hardware key. Note that the cancel key may be provided as a software key displayed on the touch panel instead of a hardware key, or both a hardware key and a software key may be provided. The USBIF 17 can detachably connect a storage medium conforming to the USB standard or the like, and can read and write data by communication conforming to the USB standard. The storage medium conforming to the USB standard is, for example, a USB memory. The MFP 10 is connected to a network via the communication IF 18 and communicates with the 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, or the like can be adopted.

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

[0014] Stored in the memory 12 as a program executable by the controller 11 is a control program 2. The control program 2 is, for example, firmware that comprehensively controls each unit 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", and "control" 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 processing of receiving data without the controller 11 making a request is also included in the concept of "the controller 11 acquires data". Also, "data" in this specification is represented by a bit string readable by the controller 11. And data having substantially the same meaning content but different formats shall be treated as the same data. The same applies to "information" in this specification.

[0015] Further, the control program 2 includes, for example, an EWS (Embedded Web Server) program which is a program that functions as a Web server. By executing the EWS program, the controller 11 can cause the MFP 10 to function as a Web server. The Web server that functions in the MFP 10 is also referred to as EWS. The controller 11 can cause a predetermined Web page to be displayed on a browser 41 (to be described later) of the PC 40 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.

[0016] 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 cause a Web page corresponding to the Web page data transmitted from the MFP 10 to be displayed 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 instruction to execute pull scanning (to be described later) to the MFP 10, for example, mobile terminals such as smartphones and tablets may also be used.

[0017] Next, the "Secure Function Lock" function will be described. The MFP 10 of this 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 setting values regarding function restriction for each user via the EWS. The setting value regarding function restriction can also be said to be a setting value regarding 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 may also be a method of receiving via the user IF 16.

[0018] 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, for example, by accessing the EWS. 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.

[0019] 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) that specifies the users to be restricted, and a function specification field 33 that specifies 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 each 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.

[0020] 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 restriction settings 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, permitting the execution of the functions, and the functions without a check are the functions specified as setting restrictions, that is, not permitting the execution of the functions. 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 just examples.

[0021] In the example shown in FIG. 2, in the function designation column 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 column 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). Also, 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 determination button (not shown) is operated, the controller 11 updates each set value in the SFL database 19 based on the input to the restriction setting screen 30.

[0022] In addition, the controller 11 stores and uses various set values not only in the SFL database 19 but also in the memory 12. For the sake of convenience, storing the set values in the memory 12 may be described as setting, etc. For the sake of convenience, the fact that the set values are stored in the memory 12 may be described as set, set value, set, etc.

[0023] 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 document. Scan data is also a type of image data. "Push Scan" generates scan data by causing the scanner 15 to read the 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 sends 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 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.

[0024] The controller 11 starts the scan control process shown in FIG. 3, for example, after the power of the MFP 10 is turned on and the control program 2 is executed to start the system. 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 of returning 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.

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

[0026] As shown in FIG. 4, in S10, the controller 11 determines whether an execution instruction for push scan has been received. Specifically, when the controller 11 receives an execution instruction to start the execution of the function "scan" by an operation on the user IF 16 of the MFP 10, it determines that an execution instruction for push scan has been received (S10: YES), and executes the request process for push scan in S11. For example, in response to receiving an operation on the user IF 16, the controller 11 transmits a request for push scan 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 an execution instruction for push scan has been received. 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 an execution instruction for pull scan has been received (S10: NO), and executes the request process for pull scan in S12.

[0027] 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 IF 16 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 IF 16, the controller 11 may determine that an execution instruction for push scan has been received without transmitting a request to the external device, and execute S11.

[0028] 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 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 document table. That is, the controller 11 executes the process without imposing a restriction on push scanning and ends the processes of FIGS. 4 and 5.

[0029] 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).

[0030] 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 the present 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 the present 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).

[0031] 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, which has been described above (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).

[0032] 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 during the login process by the controller 11, 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 where 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 where "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 in the process of FIG. 8.

[0033] Next, the processing executed by the controller 11 when receiving an instruction to execute a pulse 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 pulse scan will be described. As shown in FIG. 6, when starting the processing of S12, the controller 11 determines whether the execution of the pulse scan is set to be valid or invalid in the MFP 10 (S31). For example, the controller 11 determines based on information indicating whether the pulse scan is set to be valid or invalid and stored in the memory 12 separately from the SFL database 19. In this example, assuming that the pulse 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 determines whether user authentication is required for the instruction to execute the pulse scan using the restriction setting value corresponding to the push scan in the "Public Mode". Incidentally, when the pulse scan is set to be invalid in the MFP 10 (S31: NO), the controller 11 notifies the PC 40 that the pulse scan cannot be executed (S42). That is, when the pulse scan is set to be invalid in the MFP 10, the pulse scan is not executed regardless of who is logged in to the MFP 10.

[0034] 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 restricting the push scan in the logged-out state.

[0035] In this example, as shown in FIG. 2, since a limit setting value "limit" indicating a restriction 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.

[0036] 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.

[0037] 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 S42, the controller 11 notifies the PC 40 that it cannot execute a pulse scan.

[0038] 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 the authentication completion flag indicating the success or failure of user authentication. Incidentally, if 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 S42.

[0039] 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.

[0040] 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 Fig. 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.

[0041] In S39 of Fig. 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, since the scan process is not permitted (S39: NO), the controller 11 executes S42. Since the push scan is restricted for "User A", even if the authentication by the user authentication process in S36 is successful, the pull scan is restricted. Then, the controller 11 ends the process of Fig. 6.

[0042] Next, the process when "User A" operates the PC 40 to execute a pull scan while logged in to the MFP 10 will be described. Also in this example, the controller 11 executes the processes of S31 to S37 of Fig. 6 already described. In S32, the controller 11 identifies that the push scan 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).

[0043] 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.

[0044] If the controller 11 determines that the users match (S72: NO), it executes S74. In S74, the controller 11 determines whether the function "Scan" is restricted 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 S42.

[0045] If 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 S42.

[0046] Next, the process when "User B" operates PC40 to perform a pull scan in the state where the user is not logged in to MFP10, "Public Mode", 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. The controller 11 is in "Public Mode" in S70 of FIG. 9 (S70: NO), and since "Permission" is registered in the limit setting value corresponding to the function "Scan Process" of "User B" who has successfully authenticated (S75: NO), in S76, a value indicating permission to start scanning is set in the scan permission flag. In S39 of FIG. 6, since the controller 11 has a value indicating permission to start scanning set in the scan permission flag (S39: YES), similar to S29, it instructs the scanner 15 to start scanning (S41). That is, since there is no restriction set on push scan for "User B", the controller 11 performs a pull scan on the condition that the authentication is successful. Incidentally, before instructing the scanner 15 to start scanning in S41, the controller 11 notifies PC40 of the extension of the timeout period (S40).

[0047] For example, after the printer driver of the PC 40 establishes communication with the MFP 10 to perform pull scanning, if the state where scan data cannot be received because the scan data is not transmitted from the MFP 10 continues for a time longer than a predetermined timeout period, or if the transmission of the scan data is stopped halfway and then the state where the scan data cannot be received continues for a time longer than the timeout period, the communication established with the MFP 10 is disconnected. Note that the situation where the elapsed time of the determination target becomes longer than the timeout period is also described as the timeout period elapsing. The time of the timeout period is, for example, 90 seconds. Also, as will be described later, after starting the pull scan, when the controller 11 receives an instruction to cancel the currently executing scan job in the logged-out state, the controller 11 performs authentication of the user who gives the cancellation instruction. For this reason, there is a possibility that the timeout period elapses while the user is performing an operation of selecting a user name or an operation of inputting a password in connection with the execution of the cancellation. Note that the execution of the cancellation is also described as canceling. Therefore, before making an affirmative determination in S39 and executing S41, that is, before starting the execution of the pull scan, the controller 11 requests the PC 40 to extend the timeout period.

[0048] As the extended period to be requested, it is preferable to set the time required for the cancellation operation. For example, the time required for one operation of instructing cancellation is set to 30 seconds. The operation of instructing cancellation is an operation of performing user authentication by inputting a user name and a password. Also, in the cancellation operation, there is a possibility of an input error of the password. Therefore, as the number of times (the number of re-input times in S139 of FIG. 17 described later) that an input error of the password is permitted in the cancellation operation, 3 times is set. In this case, as the extended period to be requested, it is preferable to set a time equal to or longer than the time obtained by multiplying the time of one cancellation operation by the number of times the input of the password is permitted (90 seconds = 30 seconds * 3 times). In S40, the controller 11 transmits, for example, information indicating an extended period of 90 seconds to the PC 40 and requests to extend the timeout period by the extended period.

[0049] Furthermore, the controller 11 does not have to request the PC 40 to extend the timeout period. Also, the entity that determines whether the timeout period has elapsed may be the controller 11 (MFP 10). In this case, the controller 11 may execute the extension of the timeout period.

[0050] Next, the processing when "User B" performs a pull scan 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 FIG. 6 which have already been described. In S70 of FIG. 9, since the controller 11 determines that "User B" is logged in (S70: YES), the controller 11 executes S71 and determines whether the user who requested a pull scan by operating the PC 40 matches the logged-in user of the MFP 10. When the controller 11 determines that the users match (S72: NO), the controller 11 executes S74. Since the limit setting value corresponding to the function "scan" of "User B" is "permitted" (S75: NO), the start of the pull scan is permitted (S76). Furthermore, in S72 of FIG. 9, when the controller 11 determines that the users do not match (S72: YES), the start of the pull scan is not permitted (S73). That is, even when user authentication has succeeded for "User B" and the limit setting value corresponding to the function "scan" of "User B" in the SFL database 19 is "permitted", if the user who requested the pull scan does not match the logged-in user of the MFP 10, the pull scan is not permitted.

[0051] Next, different from the example of the SFL database 19 shown in FIG. 2, an example of executing a pull scan when a restriction setting value of "permission", which does not show a restriction on 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 "permission" for the function "scan" in "Public Mode" is registered in the SFL database 19 (S53: NO), it executes S55. The controller 11 sets a value indicating that user authentication is unnecessary for the execution instruction of the push scan in the necessity determination flag in S55. Then, the controller 11 determines in S33 of FIG. 6 that user authentication is unnecessary (S33: NO) and instructs the scanner 15 to start the scan (S41). That is, in this example, since the push scan in "Public Mode" is not restricted, the pull scan is not restricted for anyone.

[0052] 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.

[0053] Next, the operation procedure of the scan process and the screen during the scan process will be described. FIG. 18 is a screen displayed on the user IF 16, showing the screen transition from the standby screen to starting the execution of the pull scan after performing the login operation. As shown in FIG. 18(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.

[0054] When the information bar 62 is touch-operated by the controller 11, the controller 11 displays a user change screen 65 showing selection icons 66A to 66C for selecting a user as shown in FIG. 18(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 by the controller 11, the controller 11 displays a password input screen 67 as shown in FIG. 18(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 touch-operated by the controller 11, if 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, the controller 11 makes a transition to the login state.

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

[0056] Further, the controller 11 can also receive an operation instruction to change the logged-in user via the user change screen 65 in FIG. 18(b). For example, in the standby screen 60A after login in FIG. 18(d), when the information column 62 is touched and the user change screen 65 is displayed, and then the selection icon 66B of "User A" or the selection icon 66C of "User B" is touched, the password input screen 67 shown in FIG. 18(c) is displayed to receive the input of the login password. If the input password matches the data registered in the SFL database 19, it may transition to the logged-in state. That is, in the logged-in state, it may receive the login operation of another user and execute the change of the logged-in user. 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. And when the logged-in user name is touched, the controller 11 may receive a logout operation. Further, when the information column 62 on the standby screen 60A in FIG. 18(d) is touched, the controller 11 may execute logout without displaying the user change screen 65 in FIG. 18(b).

[0057] In addition, when the scan icon 61C displayed on the logout state standby screen 60 (Fig. 18(a)) or the login state standby screen 60A (Fig. 18(d)) is operated, the controller 11 receives an execution instruction for push scan. When the controller 11 receives 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 execution screen 69 shown in Fig. 18(e). Also, when the controller 11 receives an execution instruction for pulse scan from the PC 40 (S1: YES), after determining the feasibility of the above execution (S12), when starting the scan process (S41), it also displays the scan execution screen 69 shown in Fig. 18(e). Further, when the controller 11 is displaying the scan execution screen 69 shown in Fig. 18(e) on the touch panel of the user IF 16, based on a predetermined condition (Fig. 15) described later, it displays the cancel reception screen 71 shown in Fig. 18(f) instead of the scan execution screen 69. The controller 11 displays the file name to be created, etc. on the scan execution screen 69, or displays a cancel reception unit 73 for receiving user authentication information on the cancel reception screen 71, but does not display the information column 62 for performing the logout operation (Fig. 18(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. 18(d), and if in the logout state, it displays the standby screen 60 in Fig. 18(a). Therefore, when the controller 11 starts the scan process in the login state, until the end of the scan process (S3: YES) or the execution of cancellation (S8: YES) described later, it displays the scan execution screen 69 on the user IF 16 so that the logout operation and the change of the logged-in user cannot be executed. Note that the method of disabling the logout operation and the change operation of the logged-in user is not limited to the method of displaying the scan execution screen 69. For example, even after starting the scan process, the controller 11 may display the standby screens 60, 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).

[0058] 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 cancellation in the same manner as the cancellation process for one scan job described below.

[0059] 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 S41 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. 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 S41 is executed, the process shown in FIG. 3 is completed.

[0060] 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 it receives an instruction to cancel the scan job in S5. When storing the generated scan data in the memory 12 until determining whether to permit the execution of 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).

[0061] 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.

[0062] As shown in FIG. 3, when the controller 11 executes S4, in S5, it determines whether or not it has received an instruction to cancel the scan job (hereinafter sometimes referred to as a cancel instruction). As methods for the user to execute a cancel instruction for the scan job, there are a method of operating the user IF 16 of the MFP 10 to execute a cancel instruction (hereinafter referred to as a cancel instruction by user IF operation), and a method of operating the PC 40 to execute a cancel instruction (hereinafter referred to as a cancel instruction by PC operation). A cancel instruction by user IF operation is a cancel instruction by operating an operation key provided separately from the touch panel, for example, operating a cancel key. Incidentally, a cancel instruction by user IF operation may be a cancel instruction by operating a software key displayed on the touch panel. If the controller 11 does not receive a cancel instruction (S5: 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.

[0063] When the controller 11 receives a cancel instruction (S5: YES), in S6, it executes job cancel request processing. Incidentally, when the controller 11 makes an affirmative determination in S5 (S5: 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. The controller 11 temporarily stores the scan data generated until then in the memory 12. 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. Also in this case, the controller 11 may simply temporarily store the generated scan data in the memory 12. Incidentally, when the controller 11 makes an affirmative determination in S5 (S5: YES), it may temporarily stop the output of scan data and discard the scan data generated until then. And if the cancellation of the scan job described later is not executed, the reading of the original may be done again from the beginning.

[0064] Also, in response to receiving a cancellation instruction, it is not necessary to uniformly stop the output or generation of scan data. For example, when starting the process of FIG. 15 described later, the controller 11 may temporarily stop the output of scan data. That is, the output of scan data may be stopped only for the scan job of the pull scan that determines whether to permit the execution of cancellation after S101. Specifically, as will be described later, for the scan job of the pull scan that determines whether to permit the execution of cancellation according to whether it is an execution instruction of the pull scan received together with the user authentication information (S112), or whether it is in the logged-in state (S115), etc., the output of scan data may be temporarily stopped.

[0065] Furthermore, as shown in FIG. 11, when the controller 11 starts the process of S6, it checks the type of scan job (S85). First, the process when a cancellation instruction is executed after the push scan is started will be described. In this example, when the controller 11 determines that the type of scan job is not a pull scan, that is, it is a scan job of the push scan (S86: NO), it executes the job cancellation process of S88. Note that when the type of scan job confirmed in S85 is a pull scan (S86: YES), the controller 11 executes the job cancellation process of the pull scan of S87 described later.

[0066] As shown in FIG. 12, when the controller 11 starts the process of S88, it cancels the currently executing scan job. In this example, the controller 11 cancels the scan job of the push scan (S91). It completely ends the processes such as the output of scan data that had been temporarily stopped. If there is generated scan data, it is discarded. When the controller 11 executes S91, it ends the process of FIG. 11. As shown in FIG. 3, after executing S6, the controller 11 determines whether the scan job has been canceled, that is, whether S91 in FIG. 12 has been executed (S8). When the controller 11 has canceled the scan job (S8: YES), it ends the process shown in FIG. 3. The controller 11 ends the display of the scan execution screen 69 shown in FIG. 18(e), and if it is in the logged-in state, it displays the standby screen 60A in FIG. 18(d), and if it is in the logged-out state, it displays the standby screen 60 in FIG. 18(a). Note that the controller 11 may execute the processes of FIGS. 11 and 12 without temporarily stopping the execution of the scan job (such as the output of scan data) when it makes an affirmative determination in S5.

[0067] Therefore, in the case of push scan, cancellation is executed regardless of whether the cancellation instruction is given by a user IF operation or a 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 operates the user IF 16 again to give a cancellation instruction. 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, no means for receiving a cancellation instruction for a scan job is provided outside the device that receives an instruction to start scanning and the device that executes a 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 going through the job cancellation permission process (Fig. 15) described later.

[0068] Next, the processing when a cancellation instruction is given by a PC operation after pull scan is started will be described. In this example, when the controller 11 makes an affirmative determination in S86 of Fig. 11 (S86: YES) and starts the processing of S87 shown in Fig. 13, the controller 11 confirms the request source of the job cancellation, that is, confirms the method by which the cancellation instruction was issued (S92). When the cancellation instruction is not a cancellation instruction by a PC operation, that is, when the cancellation instruction is a cancellation instruction by a user IF operation (S93: NO), the controller 11 executes S94.

[0069] In this example, since the cancel instruction is a cancel instruction by PC operation (S93: YES), the controller 11 executes the job cancel process shown in FIG. 12 (S96). 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, other than 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 executes the cancel instruction from the same PC 40. For this reason, for the cancel instruction by PC operation for the pull scan, the scan job is canceled without going through the job cancel permission process (FIG. 15) described later (S91).

[0070] Next, the processing when an error occurs after the pull scan is started and a cancellation instruction is given by a user IF operation will be described. In this example, the controller 11 makes an affirmative determination in S5 of FIG. 3 (S5: YES), makes an affirmative determination in S86 of FIG. 11 (S86: YES), makes a negative determination in S93 of FIG. 13 (S93: NO), and executes S94. In S94, the controller 11 determines whether an error has occurred based on the error occurrence flag. If no error has occurred (S94: NO), the controller 11 executes the cancellation control process of S95. In this example, since an error has occurred, the controller 11 makes an affirmative determination in S94 (S94: YES) and executes S96. Therefore, even when an error occurs and a cancellation instruction is given by a user IF operation, the controller 11 executes the cancellation of the scan job (S91) without going through the job cancellation permission process (FIG. 15), which will be described later, in the same manner as the cancellation instruction for a PC operation. Note that the controller 11 may be configured to immediately end the scan job when an event that requires the scan job to be immediately ended, such as a critical error, occurs.

[0071] Next, the processing when a cancellation instruction is given by a user IF operation without an error occurring after the pull scan is started will be described. In this example, the controller 11 makes an affirmative determination in S86 of FIG. 11 (S86: YES), makes a negative determination in S93 of FIG. 13 (S93: NO), makes a negative determination in S94 (S94: NO), and executes the cancellation control process of S95. When starting the process of S95 shown in FIG. 14, the controller 11 executes the job cancellation permission process of S101. As shown in FIG. 15, when starting the process of S101, the controller 11 refers to the value of the authentication completion flag (S111) and determines whether the referred value indicates success (true), that is, whether the currently executing scan job is a pull scan job that requires user authentication (S112).

[0072] 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 judgment is made in S33 (S33: NO), S36 is not executed, and S62 and S63 in Fig. 8 are not executed. Therefore, in the case of the above two examples, the value indicating success (true) is not set in the authentication completion flag. In this case, the controller 11 makes a negative judgment in S112 (S112: NO), executes S114, sets a value indicating permission to cancel the scan job in the job cancellation flag, and ends the process in Fig. 15. The controller 11 refers to the job cancellation flag (S102). Since the job cancellation flag referred to in S102 is a value indicating permission (S103: YES), the job cancellation process shown in Fig. 12 is executed (S104). Therefore, when the function "SFL" is invalid, or when the function "SFL" is valid and there is no restriction on the function "scan" in "Public Mode", the user can instruct the MFP 10 to execute a pull scan by operating the PC 40 without having to input user authentication information, and can cancel the scan job by operating the user IF 16 without having to input user authentication information (S91).

[0073] On the other hand, when the function "SFL" is valid (S51: YES), the restriction on the function "scan" is set in "Public Mode" (S53: YES), and the user authentication information received from the PC 40 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 indicating success (true) (S62). In this case, the controller 11 makes an affirmative judgment in S112 (S112: YES) and executes S115. In S115, the controller 11 determines whether it is in the logged-in state. If the MFP 10 is in the logged-out state (S115: NO), the job cancellation permission determination process in S116 is executed. The job cancellation permission determination process will be described later.

[0074] Also, when in the logged-in state (S115: YES), the controller 11 executes the cancel user confirmation process of S117. As shown in FIG. 16, when starting the process of S117, the controller 11 determines whether the logged-in user matches the user of the scan job of the pull scan to be canceled (S121). That is, it is determined whether the logged-in user who instructed the cancellation of the scan job through the user IF16 matches the user of the user authentication information received together with the execution instruction of the pull scan. When the two users match (S122: NO), the controller 11 sets a value indicating permission to cancel the job in the job cancellation flag (S123) and ends the process shown in FIG. 16. Since the job cancellation flag indicates a value of permission (S103: YES), the controller 11 executes the job cancellation process shown in FIG. 12 (S104). Therefore, after the pull scan is started, when a cancellation instruction is given by the user IF operation in the logged-in state, if the logged-in user matches the user of the pull scan, the scan job is canceled (S91).

[0075] In addition, in S121, the condition for determining that the logged-in user matches the user of the user authentication information received together with the execution instruction of the pull scan to be canceled is that the user names exactly match. However, in this specification, for the user authentication information to correspond, it does not necessarily have to be limited to the case where 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, instead of the user name matching, when information indicating substantially the same user is shown, it may be determined that the users match. For example, when one of the two pieces of user authentication information is a user ID and the other is the user name indicating that user ID, it may be determined that the users match. Also, when the user authentication information includes information indicating the group to which the user belongs, it may be determined that the users match on the condition that they belong to the same group.

[0076] On the other hand, when the user does not match in S122 (S122: YES), the controller 11 determines whether the logged-in user matches the administrator of the MFP 10 (S124). If they match (S125: NO), the controller 11 sets a value indicating permission to cancel the job in the job cancellation flag (S123) and ends the process shown in FIG. 16. Since the job cancellation flag has a value indicating permission (S103: YES), the controller 11 executes the job cancellation process shown in FIG. 12 (S104). An administrator is a user who is permitted to perform various operations on the MFP 10 that are not permitted to general users in order to manage the MFP 10. For example, special user authentication information indicating the administrator "Admin" is registered in the SFL database 19. Therefore, when a cancellation instruction is given by the user IF operation in the logged-in state after the pull scan is started, even if the logged-in user does not match the user of the pull scan, if the logged-in user is an administrator, the scan job is cancelled (S91).

[0077] Then, when the logged-in user is not an administrator (S125: YES), the controller 11 sets a value indicating that job cancellation is not permitted in the job cancellation flag (S126), and ends the process shown in FIG. 16. The controller 11 returns to the process of FIG. 14, makes a negative determination in S103 (S103: NO), and continues the execution of the scan job by the scanner 15 without canceling the scan job (S105). 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 processes of FIGS. 13 and 11. As shown in FIG. 3, after executing S6, when the controller 11 executes S8 and does not cancel the scan job (S8: NO), that is, when S105 is executed, the controller 11 executes the process from S3 again. The scan job of the pull scan continues without being canceled. The controller 11 completes the scan if there is no scan job cancellation instruction during the continued scan (S3: YES), and when a cancellation instruction is received again (S5: YES), determines again whether to execute the cancellation (S6). Also, the controller 11 executes the process from S3 again, and if the scan has not been completed (S3: NO), executes S4, and determines that an error has occurred. Through the above-described process, the controller 11 can limit the scan job of the pull scan started by successfully authenticating the user authentication information transmitted from the PC 40 from being canceled by the operation of a user different from the user who performed the pull scan start instruction operation. Note that the controller 11 does not necessarily temporarily stop the execution of the scan job when a positive determination is made in S5. In this case, the process of S105 can be omitted.

[0078] Also, as described above, when the MFP 10 is in the logged-out state (S115: NO), the controller 11 executes the job cancellation permission determination process of S116. When starting the process of S116, the controller 11 displays a cancellation reception screen (S131 in FIG. 17). That is, in a state where the scan execution screen 69 shown in FIG. 18(e) is displayed on the touch panel of the user IF 16, when a cancellation operation is received via the user IF 16, for example, via a cancel key, the controller 11 displays the cancellation reception screen 71 shown in FIG. 18(f) on the touch panel. The controller 11 receives user authentication information on the cancellation reception screen 71.

[0079] When the controller 11 executes S131, it acquires information regarding the timeout period, and sets a predetermined time based on the period indicated by the acquired information regarding the timeout period (S132). Note that acquiring information regarding the timeout period is also described as acquiring the timeout period. Also, the period indicated by the information regarding the timeout period is simply described as the timeout period. The controller 11 acquires the timeout period from the PC 40. The PC 40 transmits to the MFP 10 the time obtained by adding the extension period requested by the controller 11 in S41 of FIG. 6 to the timeout period set in the printer driver of the PC 40 in response to the request of the controller 11. Note that the predetermined time will be described later. Also, the timing of acquiring the timeout period is not limited to the execution of S132. For example, the controller 11 may acquire the timeout period from the PC 40 immediately after requesting an extension of the timeout period to the PC 40 in S41 of FIG. 6. Alternatively, the controller 11 may acquire the timeout period from the PC 40 at the timing when it receives an instruction to execute a pull scan from the PC 40 (S10: NO in FIG. 4). In this case, the controller 11 may add the extension period requested to the PC 40 to the acquired timeout period, and set a predetermined time based on the added period.

[0080] Next, the controller 11 determines whether or not the elapsed time since the output of the scan data was stopped is equal to or less than a predetermined time (S133). As described above, when the controller 11 makes an affirmative determination in S5 (S5: YES), the controller 11 temporarily stops the output of the scan data. Further, when the time during which the printer driver of the PC 40 cannot receive the scan data continues to be longer than the timeout period, the communication established with the MFP 10 is disconnected. Therefore, when the controller 11 makes an affirmative determination in S5 and temporarily stops the output of the scan data (S5: YES), the controller 11 starts measuring the elapsed time. Then, when the measured elapsed time becomes longer than the predetermined time (S133: NO), the controller 11 sets a value indicating that job cancellation is not permitted in the job cancellation flag (S143), ends the process shown in FIG. 17, and continues the execution of the scan job (S103: NO, S105). Note that the controller 11 may execute S143 when the measured elapsed time becomes equal to or longer than the predetermined time (elapsed time ≧ predetermined time) in S113.

[0081] In this embodiment, when the printer driver of the PC 40 can no longer receive scan data from the MFP 10, if it receives even a part of the scan data from the MFP 10 before the timeout period elapses, it resets the time counted from the point when it could no longer receive the scan data, that is, it resets the time counted to determine the timeout period. Therefore, as the predetermined time in S133, for example, the time required to execute S105 in FIG. 14 and resume sending scan data by continuing the pulse scan can be set from the point when the negative determination was made in S133. As described above, the controller 11 executes generation of scan data based on the scan job until it receives a cancel instruction (S5: NO). Therefore, if the memory 12 stores scan data that was generated until the cancel instruction was received and remained without being output by stopping the output, the controller 11 can immediately send the scan data stored in the memory 12 after executing S105. In other words, if even a part of the scan data is stored in the memory 12, a cancel instruction can be received until just before the timeout period elapses. Therefore, as the predetermined time in S133, a time just before the timeout period elapses, such as 1 second before the timeout period elapses, can also be adopted. Specifically, when the default timeout period is 90 seconds and the extended period requested for extension is 90 seconds, the controller 11 sets the predetermined time to 179 seconds and makes an affirmative determination in S133 until 1 second before the timeout period elapses (S133: YES). Note that the controller 11 does not necessarily have to determine the elapsed time from the point when the output of the scan data was stopped based on the timeout period. In this case, the controller 11 may execute S134 after S131 without executing S40 in FIG. 6, or S132, S133, and S143 in FIG. 17, and determine cancellation based on user authentication, which will be described later.

[0082] Also, in S133, the elapsed time to be compared with the predetermined time does not necessarily have to be measured by the controller 11. For example, the controller 11 may inquire the PC 40 about the elapsed time since it became unable to receive scan data. Alternatively, in the determination of S133, the elapsed time does not have to be used. For example, the controller 11 may inquire the PC 40 about the remaining time until the timeout period elapses, and the controller 11 may determine in S133 whether the remaining time obtained from the PC 40 is shorter than 1 second. In this case, when it is shorter than 1 second (S133: NO), the controller 11 executes S143.

[0083] Also, the timing to start measuring the elapsed time is not limited to the time point (S5: YES) when a positive determination is made in S5 and the output of scan data is temporarily stopped. For example, the controller 11 may start measuring the elapsed time from the time point when it instructs the scanner 15 to start a pulse scan in S41, and use the measured elapsed time as the object of determination in S133. Alternatively, the controller 11 may start measuring the elapsed time from the time point when it determines that it has received an execution instruction for a pulse scan from the PC 40 (S10: NO), and use the measured elapsed time as the object of determination in S133. Also, the controller 11 may start measuring the elapsed time from the time point when it has received an execution instruction for any scan (S1: YES), and use the measured elapsed time as the object of determination in S133.

[0084] Also, when the elapsed time since the output of scan data was stopped is equal to or less than the predetermined time (S133: YES), the controller 11 determines whether user authentication information has been received (S134). As shown in FIG. 18(f), for example, the controller 11 displays a screen with a translucent cancellation reception section 73 superimposed in front of the scan execution screen 69 as a cancellation reception screen 71. The controller 11 displays a user selection field 74 and a password input field 75 in the cancellation reception section 73.

[0085] When the user selection field 74 is touched, for example, the controller 11 displays a pull-down menu and lists the user names in the pull-down menu so that they can be selected. The controller 11 displays only the users registered in the SFL database 19, that is, the users who are allowed to cancel the pull scan among the users who can log in to the MFP 10, in the list in the pull-down menu. As shown in FIG. 16, as the user who is allowed to cancel the pull scan, the user indicated by the user authentication information received together with the pull scan execution instruction or the administrator is preferable. That is, when the user who requested the pull scan gives a cancellation instruction himself or when the administrator gives a cancellation instruction, it is preferable to provide a means to give a cancellation instruction. For this reason, for example, when the user indicated by the user authentication information received together with the pull scan execution instruction is user A, the controller 11 displays user A and the administrator (admin) in the pull-down menu as shown in FIG. 18(f), and does not display other users (user B). Note that the method of displaying users in the user selection field 74 is not limited to the pull-down menu.

[0086] When the determination button of the user IF 16 (not shown) is operated in a state where the user name is selected in the user selection field 74 and the password is input in the password input field 75, the controller 11 determines that the user authentication information has been received (S134: YES) and executes user authentication based on the input information (S136). Further, after displaying the cancellation reception screen 71, until the determination button of the user IF 16 is operated, the controller 11 makes a negative determination in S134 (S134: NO) and executes the process from S132.

[0087] In S136, the controller 11 determines whether the combination of the user name selected in the user selection field 74 and the password entered in the password input field 75 matches the information registered in the SFL database 19. If they match, it is determined that the user authentication is successful (S136: YES). A value indicating that job cancellation is permitted is set in the job cancellation flag (S137), and the process shown in FIG. 17 is terminated. Since the job cancellation flag has a value indicating permission (S103: YES), the controller 11 executes the job cancellation process shown in FIG. 12 (S104). Specifically, the processes such as the output of scan data that were temporarily stopped are completely terminated. If there is generated scan data, it is discarded (S91). In this way, after the pull scan is started, when a cancellation instruction is given by the user IF operation in the logged-out state, user authentication is executed. If the user who has successfully authenticated is the user who requested the pull scan or an administrator, the scan job is cancelled. Also, the controller 11 ends the display of the cancellation reception screen 71 shown in FIG. 18(f) and displays the standby screen 60 of FIG. 18(a) in the logged-out state.

[0088] Further, the controller 11 may display all the users registered in the SFL database 19 in the list of the user selection field 74. In this case, for example, when the user authentication in S136 is successful (S136: YES), the controller 11 executes the cancel user confirmation process in FIG. 16 and may determine whether the user who executed the cancel instruction is appropriate. Specifically, if the user who executed the cancel instruction is the user who requested the plus scan (S122: NO) or is an administrator (S125: NO), a value indicating permission to cancel the scan job is set in the job cancel flag (S123), and the processes shown in FIGS. 16 and 17 are terminated. Since the job cancel flag indicates a permission value (S103: YES), the controller 11 executes the job cancel process shown in FIG. 12 (S104). Also, when the controller 11 sets a value indicating that the scan job cancellation is not permitted in the job cancel flag (S126), the process returns to the process in FIG. 17, and the process of checking the number of times of user authentication execution, which will be described later, may be advanced (S138). Further, the controller 11 may accept an operation of inputting a user name as a character string without displaying the user list on the cancel reception screen 71. Also in this case, for example, when the user authentication in S136 is successful (S136: YES), the controller 11 executes the cancel user confirmation process in FIG. 16 and may determine whether the user who executed the cancel instruction is appropriate. Also, when the controller 11 accepts the input of the password without the user name being selected or the user name being input on the cancel reception screen 71, the determination in S136 may be advanced. In this case, when the password matches the administrator password stored in the memory 12, the controller 11 makes an affirmative determination (S136: YES) and may set a value indicating permission to cancel the scan job in the job cancel flag (S137). Also, when the user authentication is successful in S136, the controller 11 may shift to the logged-in state with the user who succeeded in the user authentication as the logged-in user after canceling the plus scan.For example, after canceling the pulse scan, the controller 11 may end the display in Fig. 18(f), display the standby screen 60A in Fig. 18(d), and display the logged-in user name in the information field 62.

[0089] Also, when the combination of the user name and password is incorrect and the user authentication fails (S136: NO), the controller 11 checks the number of times the user authentication has been executed (S138). The controller 11 displays the cancellation acceptance screen 71, obtains the number of times the user authentication has been executed with the input user authentication information, that is, the execution count of S136 (S138), and determines whether the obtained execution count is greater than a predetermined re-entry count (S139). When the execution count is less than or equal to the re-entry count (S139: NO), the controller 11 executes S131 and displays the initial screen of the cancellation acceptance screen 71 with the selection of the user name reset, etc. (S131). Therefore, when the number of times the user authentication has been executed is less than or equal to the re-entry count (S139: NO) and the elapsed time is less than or equal to a predetermined time (S133: YES), the controller 11 repeatedly executes the user authentication for canceling the pulse scan.

[0090] Also, when the number of times of user authentication execution exceeds the number of re - input times (S139: YES), the controller 11 sets a value indicating that job cancellation is not permitted in the job cancellation flag (S141), and ends the process shown in FIG. 17. The controller 11 ends the display of the cancellation reception screen 71 in FIG. 18(f) and displays the scan execution screen 69 in FIG. 18(e). That is, the execution of the scan job is continued without canceling the scan job of the pull scan (S103: NO, S105). Therefore, when the user authentication associated with the cancellation instruction fails a predetermined number of times of re - input, cancellation is not performed. As described above, the number of re - input times is the number of times that allows the user's selection mistakes or password input mistakes, for example, 3 times. Note that the controller 11 does not necessarily need to set an upper limit on the number of times of allowing user authentication execution. Also, when the user authentication fails a predetermined number of times of re - input, the controller 11 does not necessarily need to accept the cancellation instruction of the pull scan thereafter. Thereby, it is possible to suppress other users from executing user authentication many times. Also, when the controller 11 does not permit cancellation (S139: YES), after ending the display of the cancellation reception screen 71 in FIG. 18(f) and displaying a screen indicating that cancellation is not permitted, the controller 11 may display the scan execution screen 69 in FIG. 18(e).

[0091] Further, before the controller 11 executes user authentication a predetermined number of times, when the elapsed time described above becomes longer than a predetermined time (S133: NO), the controller 11 sets a value indicating that job cancellation is not permitted in the job cancellation flag (S143), ends the process shown in FIG. 17, and continues the execution of the scan job (S103: NO, S105). Therefore, when the remaining time until the timeout period elapses becomes short, the controller 11 does not permit the cancellation of the pull scan. As described above, the operation of user authentication associated with cancellation requires a certain amount of operation time, such as user selection and password input. For this reason, there is a risk that communication will be disconnected due to the elapsed time expiring while the user is completing their selection or password input and operating the decision button (S134: NO), or while user authentication has failed (S139: NO). Therefore, when the elapsed time becomes longer than the predetermined time, the acceptance of cancellation instructions is ended and the pull scan is continued.

[0092] During the execution of the scan, the scan execution screen 69 shown in FIG. 18(e) and the cancellation acceptance screen 71 shown in FIG. 18(f) are being displayed. Therefore, when the MFP 10 is in the logged-out state and the authentication of the user authentication information transmitted from the PC 40 is successful and the pull scan is started, the user cannot perform an operation to display the standby screen 60 in FIG. 18(a) in order to log in. Also, when the MFP 10 is in the logged-in state and the authentication of the user authentication information transmitted from the PC 40 is successful and the pull scan is started, the user cannot operate the standby screen 60A in FIG. 18(d) in order to log out or change the logged-in user. Therefore, during the execution of the pull scan, by displaying the scan execution screen 69 or the cancellation acceptance screen 71, another user other than the user who gave the start instruction for the pull scan is restricted from logging out the MFP 10 or changing it to a new logged-in state via the standby screen 60 or the standby screen 60A in order to operate the MFP 10.

[0093] Also, in any way, during the execution of the pull scan, even if the MFP 10 is logged out or a new login state is entered, the scan job of the pull scan that has been successfully authenticated for the user authentication information transmitted from the PC 40 and started by the process described with reference to FIGS. 11 to 17 can be restricted from being canceled by the operation of a user different from the user who gave the start instruction operation of the pull scan.

[0094] Also, if, before starting the pull scan and displaying the scan execution screen 69, a user different from the user of the user authentication information received together with the execution instruction of the pull scan and different from the administrator logs in and gives a cancel instruction by user IF operation (S125: YES), cancellation is not permitted (S126). Further, if, after starting the pull scan, without displaying the scan execution screen 69, the standby screen 60A after login in FIG. 18(d) is displayed and logout operations and user change operations are accepted even during scanning, a user different from the user indicated by the user authentication information received together with the execution instruction of the pull scan can be prevented from canceling even if the user logs in and gives a cancel instruction.

[0095] In the present embodiment described above, the following effects can be obtained. After starting the pull scan, when the controller 11 of the MFP 10 receives a cancel instruction to cancel the scan job via the user IF 16 (S5: YES), it receives user authentication information via the user IF 16 (S134: YES). If the received user authentication information matches the user authentication information received together with the execution instruction of the pull scan (S136: YES), the pull scan is canceled (S137), and if they do not match, cancellation is not performed (S141, S143). Thereby, when the user who instructed the execution of the pull scan gives a cancel instruction for the scan job via the user IF 16, cancellation is permitted, and when another user gives a cancel instruction, cancellation is not allowed, so that cancellation can be executed by an appropriate user.

[0096] Also, after starting the pull scan, when the controller 11 receives a cancel instruction in the logged-out state (S115: NO), it receives user authentication information and determines whether to execute the cancel (S116). As a result, in the logged-out state, when a pull scan execution instruction accompanied by user authentication information is received, the user who gave the execution instruction can cancel by performing user authentication. Also, by performing user authentication, other users other than the user who gave the pull scan execution instruction can be prevented from canceling.

[0097] Also, after starting the pull scan in response to receiving a pull scan execution instruction together with user authentication information in the logged-out state (S39: YES, S41), when the controller 11 receives a cancel instruction by a user IF operation while remaining in the logged-out state, it receives user authentication information (S93: NO, S116) and performs user authentication (S136). As a result, if the logged-out state is detected when the pull scan execution instruction is received, that state is maintained, and user authentication can be required for a pull scan cancel instruction by a user IF operation.

[0098] Also, 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 pull scan execution instruction (S72: NO, S76), until the pull scan is terminated or canceled, the controller 11 does not accept a change of the logged-in user via the user IF 16 by displaying the scan execution screen 69 or the cancel reception screen 71. As a result, by logging in to the MFP 10 in advance, other users can be prevented from sending and executing a pull scan execution instruction. Also, other users can be prevented from logging in until the pull scan instructed by the user himself / herself is terminated or canceled.

[0099] Also, after starting the pull scan, if the controller 11 in the logged-in state receives a cancel instruction by user IF operation, and if the user authentication information of the logged-in user previously received by the login operation matches the user authentication information received together with the execution instruction of the pull scan (S122: NO), the pull scan is canceled (S123); if they do not match, it is not canceled (S122: YES, S126). Thus, when the user who instructed the execution of the pull scan matches the logged-in user logged in to the MFP 10, cancellation can be permitted. For example, if the user has logged in in advance and then moves to their own PC 40 and then executes a pull scan and wants to cancel, the user can operate the cancel key of the user IF 16 to give a cancel instruction.

[0100] Also, in response to receiving the execution instruction of the pull scan together with the user authentication information in the logged-in state (S34), if the logged-in user and the user authentication information of the execution instruction match (S72: NO), the controller 11 starts the pull scan (S76); if they do not match (S72: YES), it does not start (S73). Then, after the controller 11 in the logged-in state has the user authentication information match and starts the pull scan, if it receives a cancel instruction at the user IF 16 while remaining logged in, and if the user authentication information of the logged-in user and the cancel instruction match (S122: NO), it cancels. Thus, if the user operates the user IF 16 to log in with their own user name before executing the pull scan, the logged-in state is maintained, so after starting the pull scan from the PC 40, the user can appropriately give a cancel instruction at the user IF 16.

[0101] In addition, after the controller 11 starts the pull scan when the logged-in user matches the user indicated by the user authentication information for the pull scan execution instruction, the controller 11 displays the scan execution screen 69 or the cancellation reception screen 71. Therefore, after the start of the pull scan, until the pull scan is terminated or canceled, logout operations and user change operations are not accepted. As a result, since the user is not logged out and the logged-in user is not changed, it is possible to prevent a user different from the execution instruction from logging out or logging in and issuing a cancellation instruction. Also, it is possible to suppress the change of the logged-in user and the non-matching of the logged-in user and the user authentication information of the execution instruction.

[0102] In addition, when the controller receives a cancellation instruction via the user IF 16 after starting the push scan (S86: NO), the controller cancels the push scan (S91) without the need to receive user authentication information via the user IF 16. In the case of the push scan, since the execution instruction is performed by the user IF 16, when a cancellation instruction for the push scan is received via the user IF 16, it is highly likely that the user who issued the execution instruction and the cancellation instruction is the same user. Therefore, when a cancellation instruction for the push scan is received by the user IF 16, the usability can be improved by canceling without confirming the identity of the user authentication information.

[0103] In addition, when the controller 11 receives a cancellation instruction in the logged-out state after starting the push scan (S86: NO), the controller 11 cancels the push scan (S91) without the need to receive user authentication information via the user IF 16. Thereby, even in the logged-out state, for the push scan, the usability can be improved by canceling without confirming the identity of the user authentication information.

[0104] Also, when the controller 11 receives a cancel instruction from the source (PC40) of the execution instruction for the pulse scan after the start of the pulse scan (S93: YES), it cancels the pulse scan (S96) without the need to receive user authentication information via the user IF16. When the controller 11 starts a pulse scan, it does not receive a cancel instruction for the started pulse scan from any device other than the instructing PC40. In other words, when a cancel instruction is received after the start of the pulse scan, it means that the cancel instruction has been received from the same PC40 as the PC40 that issued the execution instruction. Therefore, in this case, by eliminating the need to confirm user authentication information and permitting cancellation, user usability can be improved. Note that user authentication information may also be confirmed in this case.

[0105] Also, when the function "SFL" is invalid (S51: NO), or when the function "SFL" is valid (S51: YES) and there is no restriction on the function "scan" in "Public Mode" (S53: NO), the controller 11 starts the pulse scan without requiring user authentication information (S33: NO). In this case, S62 and S63 are not executed, and a value (true) indicating success is not set in the authentication completion flag. When canceling due to a cancel instruction by user IF operation, the controller 11 does not request user authentication information (S112: NO) and cancels the pulse scan (S114). Thereby, when user authentication is not required for the execution instruction of the pulse scan, user usability can be improved by eliminating the need for user authentication even when canceling.

[0106] Also, when an administrator is selected in the user selection field 74 of the cancel reception screen 71 and user authentication is successful (S136: YES), the controller 11 cancels the pulse scan (S137). Thereby, the administrator can cancel the pulse scan of each user by performing user authentication. Unnecessary scan jobs can be canceled with the administrator's authority.

[0107] Also, when the controller 11 fails in user authentication when receiving a cancellation instruction (S136: NO), it requests re-entry of user authentication information (S139: NO). If the controller 11 fails in user authentication even after exceeding a predetermined number of re-entry attempts (S139: YES), it does not cancel (S141). Thus, users who fail in user authentication up to a predetermined number of times can be prevented from canceling. Also, when the elapsed time since the controller 11 stopped outputting scan data without succeeding in user authentication becomes longer than a predetermined time based on the timeout period (S133: NO), the controller 11 does not cancel (S143). Thereby, it is possible to suppress communication with an external device that has instructed execution of pull scan from timing out. Also, by repeating the cancellation instruction, it is possible to suppress the output of pull scan from being stopped and the completion of execution from being delayed.

[0108] Also, when a predetermined time shorter than the timeout period for communication with the PC 40 has elapsed while the controller 11 has not succeeded in user authentication (S136: NO) (S133: NO), the controller 11 does not cancel (S143). Thereby, it is possible to suppress the situation where it takes time for the user to make a selection or enter a password, the timeout period elapses, and communication between the MFP 10 and the PC 40 that is the instruction source of pull scan is disconnected.

[0109] Also, the controller 11 can acquire information regarding the timeout period for communication with the transmission source of the pull scan execution instruction (such as the printer driver of the PC 40) from the transmission source of the pull scan execution instruction. When a predetermined time shorter than the timeout period acquired from the PC 40 has elapsed while the controller 11 has not succeeded in user authentication (S133: NO), the controller 11 does not cancel (S143). Thereby, it is possible to acquire timeout period information from the PC 40 and appropriately determine the timing to end accepting the cancellation instruction based on the time indicated by the acquired timeout period information. It is possible to suppress a timeout while the user authentication has not succeeded.

[0110] Also, in S40, the controller 11 requests the PC 40 to extend the timeout period. Then, if a predetermined time, which is shorter than the sum of the timeout period and the requested extension period, has elapsed while the user authentication has not been successful (S133: NO), the controller 11 does not cancel (S143). Thus, when the default timeout period is short, by requesting an extension with the extension period being the time required for user authentication when accepting a cancel instruction, the time for accepting user authentication can be ensured. The time for the user to execute a cancel instruction can be ensured.

[0111] Also, as described above, a timeout period is set for the communication between the controller 11 and the PC 40, and when a time longer than the time indicated by the timeout period has passed without the scan data being transmitted, a timeout occurs. After starting the pulse scan, in response to receiving a cancel instruction by a user IF operation (S5: YES), the controller 11 stores the scan data generated by the scan in the memory 12 and temporarily stops the output of the scan data. When the user authentication is not successful (S136: NO, S139: YES, S133: NO), the controller 11 transmits the scan data stored in the memory 12 to the PC 40 and continues the pulse scan (S105). The controller 11 resumes the output of the scan data and the like that has been temporarily stopped. Thus, by reading out and transmitting the scan data generated until the cancel instruction is received from the memory 12, the transmission of the scan data can be started as quickly as possible after it is determined that cancellation will not occur, and the communication between the controller 11 and the PC 40 timing out can be suppressed. On the other hand, when the user authentication is successful (S136: YES), the controller 11 discards the scan data stored in the memory 12 (S91) and does not transmit it to the PC 40. Thus, it is possible to suppress a part of the canceled scan data and the like from being transmitted to the PC 40.

[0112] In addition, when the controller 11 receives an execution instruction for a pull scan together with user authentication information and receives a request to execute a pull scan that requires user authentication based on the user authentication information (S37: YES, S39: YES), it requests the source (PC40) of the pull scan execution instruction to extend the timeout period (S40). As a result, when it is determined to execute a scan job for a pull scan that requires user authentication for a cancel instruction, the timeout period can be requested to be extended at the point in time when this is determined. Note that the timing for requesting an extension of the timeout period may be another timing. For example, the controller 11 may request the PC40 to extend the timeout period at the timing when it first makes an affirmative determination in S5 after starting the process of FIG. 3 (S5: YES), or at the timing when it makes an affirmative determination in S86 (S86: YES).

[0113] In addition, when the controller 11 receives a cancel instruction on the cancel reception screen 71 of FIG. 18(f), it displays a list of users who can log in to the MFP 10 in the user selection field 74, accepts the selection of a user, accepts the selected user as user authentication information (S134: YES), and executes user authentication (S136). As a result, compared to a configuration in which the user name is directly input, the burden of the user name input operation can be reduced. In addition, input errors of the user name can be reduced, and since the user can be selected quickly, user authentication can be completed before the timeout period elapses.

[0114] In addition, the controller 11 includes only the users who are permitted to execute the cancellation of the pull scan among the users who can log in to the MFP 10 (users registered in the SFL database 19) in the user selection field 74 and displays them in a pull-down menu (see FIG. 18(f)). When the controller 11 receives a cancel instruction, it accepts the password of the user selected in the user selection field 74 in the password input field 75 and executes user authentication (S136). As a result, the occurrence of user selection errors can be more reliably suppressed, and the user can input quickly. As a result, the time for user authentication can be shortened, and the occurrence of timeouts can be more reliably suppressed.

[0115] Also, the controller 11 determines whether an error has occurred in the MFP 10 (S4, S94). After starting the pull scan (S86: YES), if the controller 11 determines that an error has occurred (S94: YES), when canceling the pull scan, it cancels the pull scan without requesting user authentication information (S96). Thereby, a means for quickly terminating a scan job in which an error has occurred can be provided to the user. When an error such as out-of-memory occurs after starting the pull scan, by canceling without requesting user authentication, it is possible to suppress the continuation of the pull scan in a state where an error has occurred. It is possible to suppress transmitting scan data in which a read error has occurred. In other words, even if an error occurs, the scan job can be continued as long as possible, such as continuing to transmit the created scan data until the user gives a cancel instruction. When, for example, a paper jam in the ADF is regarded as an error occurrence, the user can select whether to perform a cancel operation or to remove the error event and continue the scan job, for example, by removing the paper jam in the ADF.

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

[0117] The controller 11 may execute the user authentication process at S36 in FIG. 6 and the scan permission confirmation process at S38 as follows. In this example, in the user authentication process executed at S36, it is determined whether the user operating the PC 40 matches the user logged in to the MFP 10 (the processes of S70 to S72 in FIG. 9). First, in the user authentication process executed by the controller 11 at 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 controller 11 determines that the MFP 10 has already been logged in (S70: YES), it proceeds to S71 and 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), it proceeds to S62 (FIG. 8), sets a flag indicating that the user authentication has succeeded, and proceeds to S37. Even if the controller 11 determines that it is not logged in (S70: NO), it proceeds to S62, sets a value indicating that the user authentication has succeeded in the authentication completion flag, and proceeds to S37. On the other hand, if the controller 11 determines that the users do not match (S72: NO), it proceeds to S63, sets a value indicating that the user authentication has failed in the authentication completion flag, and proceeds to S37.

[0118] 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" by 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" by the user who has successfully authenticated (S75: NO), the controller 11 proceeds to S76 and permits the start of the pull scan.

[0119] (Other Embodiments) The reading device is not limited to the above-described embodiment, and various modifications are possible without departing from the spirit thereof. The order, content, etc. of the processes shown in FIGS. 3 to 17 in the above embodiment are examples. For example, in the above embodiment, 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 only needs to confirm the registration of the user in S36 (S61) and does not need to 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 the execution instruction of the pull scan 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 the controller 11 starts the push scan in the logged-in state, if it 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 logged-in user's password. Also, the controller 11 does not have to determine whether the user who issued the cancel instruction is an administrator. Also, the controller 11 does not have to request the PC 40 to extend the timeout period. Also, a configuration may be adopted in which processing for determining whether an error has occurred in the MFP 10 (S4, FIG. 10, S94) and the like is not executed. In this case, when the controller 11 makes a negative determination in S3 of FIG. 3 (S3: NO), subsequently, in S5, it determines whether a cancel instruction has been received. Also, when the controller 11 makes a negative determination in S93 of FIG. 13 (S93: NO), that is, when a cancel instruction by a user IF operation is received, it executes the cancel control process of S95. Also, while the scan execution screen 69 is being displayed, the controller 11 may receive a login operation by an administrator by receiving a predetermined operation on the user IF 16. Thereby, even during the scan execution in which the scan execution screen 69 is displayed, an administrator can log in and cancel.

[0120] In the above-described embodiment, the controller 11 uses the SFL database 19 to perform authentication of the user name and password and restriction of functions, but it may perform authentication and function restriction 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 perform restriction of 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 perform function restriction 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.

[0121] In the above-described embodiment, the restriction setting value for the "SFL" function was set using the web page (home screen 20) transmitted from the controller 11 of the MFP 10. Instead of this, the restriction setting value for the "SFL" function may be set by operating the user IF 16 of the MFP 10. Therefore, the controller 11 may accept changes in the restriction values, etc., in the same manner as the web page, in response to operations on the user IF 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, but the reading device may be a device capable of executing only the function "scanner".

Explanation of Signs

[0122] 10…MFC (reading device), 11…controller, 15…scanner, 16…user IF, 19…SFL database, 40…PC.

Claims

1. A user interface, 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, the controller is capable of starting the pull scan in response to receiving the execution instruction of the pull scan together with user authentication information, the controller after starting the pull scan, when receiving a cancel instruction via the user interface, receives user authentication information via the user interface, and if the user authentication information received via the user interface corresponds to the user authentication information received together with the execution instruction of the pull scan, cancels the pull scan, and if not, does not cancel it, and is configured as such, a reading device.

2. The controller after starting the pull scan, in a non-logged-in state, in response to receiving the cancel instruction via the user interface, receives the user authentication information via the user interface, when receiving the cancel instruction via the user interface, if the user authentication information received via the user interface corresponds to the user authentication information received together with the execution instruction of the pull scan, cancels the pull scan, and if not, does not cancel it, and is configured as such, the reading device according to claim 1.

3. The controller is configured to start the pull scan in response to receiving the execution instruction of the pull scan together with the user authentication information in a non-logged-in state, after starting the pull scan by receiving the execution instruction of the pull scan together with the user authentication information in a non-logged-in state, in a still non-logged-in state, in response to receiving the cancel instruction at the user interface, receives the user authentication information via the user interface, if the received user authentication information corresponds to the user authentication information received together with the execution instruction of the pull scan, cancels the pull scan, and if not, does not cancel it, and is configured as such, the reading device according to claim 2.

4. ​ The controller is configured such that: when receiving an execution instruction of the pulse scan together with the user authentication information while being logged in, if the user authentication information of the logged-in user corresponds to the user authentication information received together with the execution instruction of the pulse scan, the pulse scan is started; if not, the pulse scan is not started. The controller is configured such that: after starting 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 of the pulse scan, until the pulse scan is terminated or canceled, changes to the logged-in user via the user interface are not accepted. The reading device according to claim 3. **Claim 5** The controller is configured such that: after starting the pulse scan, when receiving a cancel instruction via the user interface while not being logged in, the user authentication information is received via the user interface. when receiving the cancel instruction via the user interface, if the user authentication information received via the user interface corresponds to the user authentication information received together with the execution instruction of the pulse scan, the pulse scan is canceled; if not, the pulse scan is not canceled. The controller is configured such that: after starting the pulse scan, when receiving a cancel instruction via the user interface while being logged in, if the user authentication information of the logged-in user, which was previously accepted by a login operation via the user interface, corresponds to the user authentication information received together with the execution instruction of the pulse scan, the pulse scan is canceled; if not, the pulse scan is not canceled. The reading device according to claim 1 or claim 2. **Claim 6** The controller is configured such that: when receiving an execution instruction of the pulse scan together with the user authentication information while being logged in, if the user authentication information of the logged-in user corresponds to the user authentication information received together with the execution instruction of the pulse scan, the pulse scan is started; if not, the pulse scan is not started. The controller is configured such that: After starting the pull scan because the user authentication information of the logged-in user corresponded to the user authentication information received together with the execution instruction of the pull scan, if a cancel instruction is received at the user interface while remaining logged in, if 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, the pull scan is canceled, and if it does not correspond, it is not canceled, The reading device according to claim 5, which is configured as described above.

7. The controller is After starting the pull scan because the user authentication information of the logged-in user corresponded to the user authentication information received together with the execution instruction of the pull scan, until the pull scan is completed or canceled, a logout operation via the user interface is not accepted. The reading device according to claim 6, which is configured as described above.

8. The controller is It is possible to execute a push scan in which the scanner reads a document according to an execution instruction corresponding to an operation on the user interface. The controller is It is possible to start the push scan in response to receiving an execution instruction of the push scan via the user interface. The controller is When a cancel instruction is received via the user interface If the cancel instruction via the user interface is received after the start of the pull scan, if the user authentication information received via the user interface at the time of receiving the cancel instruction corresponds to the user authentication information received together with the execution instruction of the pull scan, the pull scan is canceled, and if it does not correspond, it is not canceled. It is configured as described above. The controller is If the cancel instruction via the user interface is received after the start of the push scan, the push scan is canceled without the need to receive the user authentication information via the user interface. The reading device according to claim 1 or claim 2, which is configured as described above.

9. The controller is It is also configured such that, in a non-logged-in state, in response to receiving an execution instruction for the push scan via the user interface, the push scan is started. The controller when receiving the cancel instruction via the user interface if, after starting the pull scan by receiving an execution instruction for the pull scan together with the user authentication information in a non-logged-in state, and then receiving it while remaining non-logged-in, the user authentication information is received via the user interface, and if the received user authentication information corresponds to the user authentication information received together with the execution instruction for the pull scan, the pull scan is canceled, and if not, it is not canceled. The reading device according to claim 8, wherein, if it is received while remaining non-logged-in after starting the push scan, the push scan is canceled without the need to receive the user authentication information via the user interface.

10. The controller is also configured to be able to receive the cancel instruction from the source of the execution instruction for the pull scan. The controller when receiving the cancel instruction after starting the pull scan if the cancel instruction is received via the user interface, and if the user authentication information received via the user interface when receiving the cancel instruction corresponds to the user authentication information received together with the execution instruction for the pull scan, the pull scan is canceled, and if not, it is not canceled. The reading device according to claim 1 or claim 2, wherein, if the cancel instruction is received from the source of the execution instruction for the pull scan, the pull scan is canceled without the need to receive the user authentication information via the user interface.

11. The controller is also capable of starting the pull scan in response to receiving an execution instruction for the pull scan without requiring the user authentication information. The controller when receiving the cancel instruction after starting the pull scan If the pull scan was started in response to receiving the execution instruction for the pull scan together with the user authentication information, then when the cancel instruction is received, if the user authentication information received via the user interface at that time corresponds to the user authentication information received together with the execution instruction for the pull scan, the pull scan is canceled; if not, it is not canceled. The reading device according to claim 1 or claim 2, which is configured such that, if the pull scan was started in response to receiving the execution instruction for the pull scan without requiring the user authentication information, the pull scan is canceled without the need to receive the user authentication information via the user interface.

12. The controller When receiving the cancel instruction, if the user authentication information received via the user interface even does not correspond to the user authentication information received together with the execution instruction for the pull scan, but corresponds to the information indicating the administrator of the reading device, the pull scan is canceled. The reading device according to claim 1 or claim 2, which is configured such that, if it does not correspond to the user authentication information received together with the execution instruction for the pull scan and does not correspond to the information indicating the administrator of the reading device, it is not canceled.

13. The controller When receiving the cancel instruction, if the user authentication information received via the user interface in response to the fact that the user authentication information received via the user interface does not correspond to the user authentication information received together with the execution instruction for the pull scan, is configured to request re-entry of the user authentication information. The controller Even if the number of re-entry attempts exceeds a predetermined number, if the received user authentication information does not correspond to the user authentication information received together with the execution instruction for the pull scan, or if a predetermined time has elapsed while the received user authentication information does not correspond to the user authentication information received together with the execution instruction for the pull scan, it is configured not to cancel. The reading device according to claim 1 or claim 2.

14. The controller The reading device according to claim 1 or claim 2, which is configured not to cancel if a predetermined time has elapsed while the user information corresponding to the user authentication information received together with the execution instruction for the pull scan is not input.

15. The controller is configured such that: when a predetermined time shorter than the communication timeout period with the sender of the pull scan execution instruction has elapsed without the user information corresponding to the user authentication information received together with the pull scan execution instruction being input, cancellation is not performed. The reading device according to claim 14.

16. The controller is configured such that: it is possible to obtain information regarding the timeout period for communication with the sender of the pull scan execution instruction from the sender of the pull scan execution instruction; The controller is configured such that: when a predetermined time, which is a time based on the information regarding the timeout period obtained from the sender of the pull scan execution instruction and is shorter than the communication timeout period with the sender of the pull scan execution instruction, has elapsed without the user information corresponding to the user authentication information received together with the pull scan execution instruction being input, cancellation is not performed. The reading device according to claim 15.

17. The controller is configured such that: it is possible to request an extension of the timeout period for communication with the sender of the pull scan execution instruction to the sender of the pull scan execution instruction; The controller is configured such that: when a predetermined time, which is shorter than the total of the timeout period indicated by the information obtained from the sender of the pull scan execution instruction and the requested extension period, has elapsed without the user information corresponding to the user authentication information received together with the pull scan execution instruction being input, cancellation is not performed. The reading device according to claim 16.

18. The communication between the reading device and the sender of the pull scan execution instruction is such that: when time passes without scan data being transmitted from the reading device to the sender of the pull scan execution instruction, a timeout occurs; The controller is configured such that: after starting the pull scan, in response to receiving a cancellation instruction at the user interface, the scan data generated by the scan is stored in the memory and the output of the scan data is temporarily stopped; The controller is configured such that: the user authentication information received via the user interface is If it does not correspond to the user authentication information received together with the execution instruction of the pull scan, continue the pull scan, including transmitting the scan data stored in the memory to the transmission source of the execution instruction of the pull scan. If it corresponds to the user authentication information received together with the execution instruction of the pull scan, cancel the pull scan, including not transmitting the scan data stored in the memory to the transmission source of the execution instruction of the pull scan. The reading device according to claim 1 or claim 2 is configured as such.

19. The controller is capable of requesting the transmission source of the execution instruction of the pull scan to extend the timeout period for communication with the transmission source of the execution instruction of the pull scan. The controller When receiving the execution instruction of the pull scan together with user authentication information and receiving a request to execute the pull scan that requires user authentication based on the user authentication information, request the transmission source of the execution instruction of the pull scan to extend the timeout period. The reading device according to claim 1 or claim 2.

20. The communication between the reading device and the transmission source of the execution instruction of the pull scan times out when time passes without the scan data being transmitted from the reading device to the transmission source of the execution instruction of the pull scan. The controller After starting the pull scan, when receiving the cancel instruction at the user interface, display a list of users who can log in to the reading device on the user interface, receive an operation of selecting any user from the list, and receive the selected user as the user authentication information. It is configured as such. The controller If the user authentication information received via the user interface corresponds to the user authentication information received together with the execution instruction of the pull scan, cancel the pull scan, and if it does not correspond, do not cancel it. The reading device according to claim 1 or claim 2 is configured as such.

21. The controller is configured to display only the users who are permitted to cancel the pull scan among the users who can log in to the reading device in the list on the user interface. The controller After starting the pull scan, when receiving the cancel instruction at the user interface, a list of only the users who are permitted to execute the cancellation of the pull scan is displayed on the user interface, an operation of selecting any user from the list is received, the password of the selected user is received, and the selected user and the received password are received as the user authentication information, and it is configured as follows: The controller is: If the user and password received via the user interface correspond to the user authentication information received together with the execution instruction of the pull scan, the pull scan is canceled; if they do not correspond, the pull scan is not canceled. The reading device according to claim 20, which is configured as follows. **Claim 22** The controller is: It 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, when receiving a cancel instruction via the user interface, the pull scan is canceled without the need to receive the user authentication information via the user interface. The reading device according to claim 1 or claim 2, which is configured as follows.

Images