Reading device

Abstract

To provide a reading device that can make an appropriate user execute the cancellation of scanning.SOLUTION: After starting a pulse scan, when a cancel instruction to cancel a scan job is received via a user IF 16, if user authentication information received via the user IF 16 matches user authentication information received together with a pull scan execution instruction (S122: NO), a controller 11 of an MFP 10 cancels the pull scan (S123), and if they do not match, does not cancel it (S122: YES, S126). 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 16

Description

Technical Field

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

Background Art

[0002] Patent Document 1 describes a reading device capable of executing pulse scanning 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 pulse scanning is registered, and when an execution instruction for pulse scanning 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 pulse scanning.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In scanning using a reading device, there may be a case where it is desired to cancel the execution after instructing the execution of scanning. 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 cancellation of scanning.

Means for Solving the Problems

[0006] In order to solve the above problems, the reading device disclosed in this embodiment includes a user interface, a scanner, and a controller. The controller is capable of executing a pull scan that causes the scanner to read a document according to an execution instruction from an external device. The controller is capable of starting the pull scan in response to receiving the execution instruction for the pull scan together with user authentication information. After starting the pull scan, if the controller receives a cancel instruction via the user interface, the controller cancels the pull scan 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, and does not cancel it if it does not correspond.

[0007] In the above configuration, after starting the pull scan, if the controller receives a cancel instruction via the user interface, the controller cancels the pull scan 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, and does not cancel it if it does not correspond. As a result, when the user who instructed the execution of the pull scan instructs cancellation via the user interface, cancellation is permitted, and when another user instructs cancellation, cancellation can be prevented.

Effect of the Invention

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

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

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 connected to each other via a bus 1 so as to be communicable with each other.

[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 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 as a hardware key, or both a hardware key and a software key may be provided. The USBIF 17 can detachably connect a storage medium compatible with the USB standard or the like, and can read and write data by communication conforming to the USB standard. The storage medium compatible with 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 a 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 that is 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 type 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 process 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 the same substantial meaning content but different formats shall be treated as the same data. The same applies to "information" in this specification.

[0015] In addition, the control program 2 includes, for example, an EWS (Embedded Web Server) 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 the pull scan (to be described later) to the MFP 10, such as mobile terminals like smartphones and tablets, may also be used.

[0017] Next, the "Secure Function Lock" function will be described. The MFP 10 of the present embodiment has a "Secure Function Lock" function (hereinafter sometimes referred to as the SFL function). The SFL function is a function that sets whether to permit or not permit each function of the MFP 10 for each user and restricts the execution of functions that are 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, setting values regarding the activation / inactivation of the SFL function, user registration, password registration, and 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 that receives functions restricted for each user. The controller 11 provides a web page to the browser 41 of the PC 40 by accessing the EWS, for example. When an administrator login operation is performed on the provided web page, the controller 11 provides the PC 40 with a web page for setting the activation / inactivation 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 entering 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 a checkbox indicating whether to set a restriction 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 individual functions of "FAX transmission" and "FAX reception", and there is a checkbox for each individual function. The function "USB" includes individual functions of "USB direct print" and "Scan to USB", and there is a checkbox for each individual function. "Web connection" includes individual functions of "Upload" and "Download", and there is a checkbox 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 controller 11 is operated with a decision button (not shown), it updates each set value in the SFL database 19 based on the input to the restriction setting screen 30.

[0022] Note that 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 value in the memory 12 may be described as setting, etc. For the sake of convenience, the fact that the set value is stored in the memory 12 may be described as set, set up, 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 transmits the scan data. As the output destination of the data by push scan, a PC 40, a device connected to the MFP 10, for example, a device connected via the USB IF 17 or the communication IF 18 can be specified. "Pull Scan" is a scan that generates scan data by causing the scanner 15 to read the 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 of FIG. 3 is not limited to the condition for starting the system. For example, the controller 11 may start the process of 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). When it determines that an execution instruction 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 or not it has received an execution instruction for push scan. Specifically, when the controller 11 receives an execution instruction to start the execution of the function "scan" by an operation on the user IF 16 of the MFP 10, it determines that it has received an execution instruction for push scan (S10: YES), and executes the request process for push scan in S11. For example, in response to receiving an operation on the user IF 16, the controller 11 transmits a push scan request to an external device (in this example, the PC 40). The external device that has received the request returns an execution instruction for "scan" to the MFP 10. When receiving this reply, the controller 11 determines that it has received an execution instruction for push scan. Also, when an operation to start scan is performed in the external device and the controller 11 has received an execution instruction transmitted from the external device, it determines that it has received an execution instruction for pull scan (S10: NO), and executes the request process for pull scan in S12.

[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 it has received an execution instruction for push scan 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 a push scan 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 referred to as "Public Mode" for convenience. For example, the SFL database 19 stores information indicating whether the function "SFL" is enabled "ON" or disabled "OFF" (hereinafter sometimes referred to as the function "SFL" information). In S21, the controller 11 determines the function "SFL" information of the SFL database 19 stored in the memory 12. When the controller 11 determines that the function "SFL" information indicates disabled (S21: NO), it executes S29 and instructs the scanner 15 to start scanning so as to read the document set on the document table. That is, the controller 11 executes the process without imposing a restriction on the push scan, and ends the processes of FIGS. 4 and 5.

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

[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 as already described (S28), and ends the processes of FIGS. 4 and 5. Incidentally, when "User B" is logged in, since the restriction setting value "ON" that does not restrict the function "Scan" for "User B" is registered in the SFL database 19 (S27: NO, see FIG. 2), the scan process is started (S29).

[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 in the login process, the MFP 10 performs various processes assuming that it has entered the login state corresponding to the input user authentication information. For example, when the user ID "User A" and the corresponding password are input, the controller 11 causes the MFP 10 to perform various processes assuming that it has entered the login state corresponding to the input "User A". It can also be said that the user authentication information registered in the SFL database 19 is the user authentication information of the users permitted to log in to the MFP 10. Incidentally, 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". Incidentally, the input of the user ID and password in the login process may be performed by bringing an ID card corresponding to the user ID registered in the SFL database 19 close to or into contact with the MFP 10. Also, the information used in the login process may be stored in an area other than the SFL database 19 in the memory 12. In this case, the controller 11 may refer to that area in the memory 12 during the login process and during the process of FIG. 8.

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

[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 that the push scan in the logged-out state is restricted.

[0035] In this example, as shown in FIG. 2, since a limit setting value “restriction” 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. Further, after receiving the GET request, the PC 40 may receive the user ID and password from the user and transmit them as response data.

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

[0038] Here, when the controller 11 receives 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 registers 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. In addition, when the user authentication information received from the PC 40 by the controller 11 is not registered in the SFL database 19 in S61 (S61: NO), it sets a value (false) indicating that the user authentication has failed in the authentication completion flag (S63). When a value (false) indicating that the user authentication has failed is set, the controller 11 determines in S37 of FIG. 6 that the user authentication has failed (S37: NO) and executes S41.

[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 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, which has been described above, at S74. In this example, for the "Scan" function corresponding to "User A" in the SFL database 19, a limit setting value "Restriction" indicating a restriction is registered (see Figure 2). Therefore, the controller 11 determines at S75 that there is a restriction on the "Scan" function (S75: YES), and at S73, sets a value indicating that the start of scanning is not permitted in the scan permission flag.

[0041] In S39 of Figure 6, since the controller 11 determines that a value indicating that the start of scanning is not permitted is set in the scan permission flag, that is, the scan process is not permitted (S39: NO), it executes S41. 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 Figure 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 in Figure 6, which have been described above. At S32, the controller 11 identifies that the push scan in "Public Mode" is restricted, and at 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] When the controller 11 determines that the users match (S72: NO), it executes S74. In S74, the controller 11 determines whether a restriction on the function "Scan" is set for the user who successfully authenticated in S36. Since the function "Scan" for the user A who successfully authenticated is restricted in the SFL database 19 (S75: YES), the controller 11 executes S73 and does not permit the start of the scan process (pulse scan). The controller 11 executes S39 of FIG. 6. As already described, since the scan process is not permitted (S39: NO), it executes S41.

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

[0046] Next, the processing when "User B" operates PC40 to perform pull scanning 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 that have already been described. In S70 of FIG. 9, since it is in "Public Mode" (S70: NO) and "Permission" is registered in the restriction setting value corresponding to the function "scanning process" of "User B" who has succeeded in user authentication (S75: NO), in S76, a value indicating permission to start scanning is set in the scan permission flag. In S39 of FIG. 6, since a value indicating permission to start scanning is set in the scan permission flag (S39: YES), similar to S29, the controller 11 instructs the scanner 15 to start scanning (S40). That is, since there is no restriction set on push scanning for "User B", the controller 11 performs pull scanning on the condition that the authentication is successful.

[0047] 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 processing of S31 to S37 in FIG. 6 which has already been described. Since the controller 11 is in the state where "User B" is logged in at S70 in FIG. 9 (S70: YES), it executes S71 and determines whether the user who requested a pull scan by operating the PC 40 matches the logged-in user of the MFP 10. When the controller 11 determines that the users match (S72: NO), it executes S74. Since the restriction setting value corresponding to the function "Scan" of "User B" is "Permit" (S75: NO), it permits the start of the pull scan (S76). Incidentally, when the controller 11 determines in S72 of FIG. 9 that the users do not match (S72: YES), it does not permit the start of the pull scan (S73). That is, even when user authentication has succeeded for "User B" and the restriction setting value corresponding to the function "Scan" of "User B" is "Permit" in the SFL database 19, 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.

[0048] 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 not required for the execution instruction of the push scan in the necessity determination flag in S55. Then, in S33 of FIG. 6, the controller 11 determines that user authentication is not required (S33: NO) and instructs the scanner 15 to start the scan (S40). That is, in this example, since the push scan in "Public Mode" is not restricted, the pull scan is not restricted for anyone.

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

[0050] Next, the operation procedure of the scanning process and the screen during scanning will be described. FIG. 17 shows the screen displayed on the user IF 16, and shows the screen transition from the standby screen to starting the execution of the pull scan after performing the login operation. As shown in FIG. 17(a), the controller 11 displays icons 61A to 61E for executing respective functions 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.

[0051] When the information bar 62 is touched by the controller 11, the controller 11 displays a user change screen 65 displaying selection icons 66A to 66C for selecting a user as shown in FIG. 17(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. 17(c), accepts a login password by the input key 68A, and displays it in the password display column 68B. When the OK button 68C is touched 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.

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

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

[0054] Also, when the scan icon 61C displayed on the logout state standby screen 60 (Fig. 17(a)) or the login state standby screen 60A (Fig. 17(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 in progress screen 69 shown in Fig. 17(e). Also, when the controller 11 receives an execution instruction for pull scan from the PC 40 (S1: YES), after determining the feasibility of the above execution (S12), when starting the scan process (S40) as well, it displays the scan in progress screen 69 shown in Fig. 17(e). The controller 11 displays the file name to be created, etc. on the scan in progress screen 69, but does not display the information column 62 for performing the logout operation (Fig. 17(e)). When the scan process is completed (S3: YES), the controller 11 displays the standby screen 60A in Fig. 17(d) if it is in the login state, and displays the standby screen 60 in Fig. 17(a) if it is in the logout state. Therefore, when the controller 11 starts the scan process in the login state, until the end of the scan process (S3: YES) or when canceling (S8: YES) described later, it causes the scan in progress screen 69 to be displayed on the user IF 16, and makes it impossible to perform the logout operation or change the logged-in user. Performing cancellation is also described as canceling. Note that the method of making it impossible to perform the logout operation or the logged-in user change operation is not limited to the method of displaying the scan in progress screen 69. For example, even after starting the scan process, the controller 11 may display the standby screens 60 and 60A and display the information column 62, but may disable the operation on the information column 62. Also, the controller 11 may be configured to receive the logout operation or the logged-in user change operation via the user IF 16 even during the scan process (while scanning) until the scan process is terminated or canceled.

[0055] Next, a process will be described in which the controller 11 receives an instruction to cancel a job (hereinafter sometimes referred to as a scan job) generated based on an instruction to execute a scan received from a user. In the following description, to avoid complication, 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 execution of cancellation in the same way as the cancellation process for one scan job described below.

[0056] As shown in FIG. 3, when the controller 11 executes the scan request process of S2, in the scan request process of S2, if the "push scan" started by S29 or the "pull scan" started by S40 is being continued (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 S40 is executed, the process shown in FIG. 3 is completed.

[0057] As shown in FIG. 10, when starting the process of S4, the controller 11 determines whether an error has occurred in the MFP 10 (S80). The error that the controller 11 determines in S80 is, for example, an error that affects other processes by continuing the scan process or an error that makes it difficult to continue the scan process. Specifically, it is a state where the storage capacity of the memory 12 becomes insufficient (hereinafter sometimes referred to as memory full). As will be described later, the controller 11 continues to generate scan data based on the scan job until receiving an instruction to cancel the scan job in 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 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).

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

[0059] 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 give a cancel instruction for the scan job, there are a method of operating the user IF 16 of the MFP 10 to give a cancel instruction (hereinafter referred to as a cancel instruction by user IF operation), and a method of operating the PC 40 to give a cancel instruction (hereinafter referred to as a cancel instruction by PC operation). The cancel instruction by user IF operation is a cancel instruction by operating an operation key provided separately from the touch panel, for example, operating a cancel key. Incidentally, the cancel instruction by user IF operation may also 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.

[0060] When the controller 11 receives a cancel instruction (S5: YES), in S6, it executes job cancellation request processing. Note that 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. Also, the controller 11 may not stop the reading of the original by the scanner 15 and the generation of scan data, and may only temporarily stop the output of scan data. In this case, the controller 11 may simply temporarily store the generated scan data in the memory 12. Further, as shown in FIG. 11, when the controller 11 starts the processing of S6, it checks the type of the scan job (S85). First, the processing when a cancel instruction is given after the push scan is started will be described. In this example, when the type of the scan job is not a pull scan, that is, when it is determined that the scan job is a push scan (S86: NO), the controller 11 executes the job cancellation processing of S88. Note that when the type of the scan job confirmed in S85 is a pull scan (S86: YES), the controller 11 executes the job cancellation processing for the pull scan of S87, which will be described later.

[0061] 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 the controller 11 executes S6, it determines whether it has executed the cancellation of the scan job, that is, whether it has executed S91 in FIG. 12 (S8). When the controller 11 has executed the cancellation of 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. 17(d), and if it is in the logged-out state, it displays the standby screen 60 in FIG. 17(a). Incidentally, 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.

[0062] 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 IF16 of the MFP10 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 IF16 operates the user IF16 again to give a cancellation instruction. Also, the means for receiving a cancellation instruction for a scan job is basically not provided outside the apparatus related to that scan job. Specifically, means for receiving a cancellation instruction for a scan job is not provided outside the apparatus that receives an instruction to start scanning and the apparatus that executes the scan job based on the received instruction. That is, basically, a cancellation instruction is not given from another apparatus not related to the execution of the scan job. In the case of push scan, both the apparatus that receives an instruction to start scanning and the apparatus that executes the scan job are the MFP10. Therefore, it is appropriate to provide the means for receiving a cancellation instruction for a scan job only in the MFP10. Thus, 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.

[0063] Next, the processing when a cancellation instruction is given by a PC operation after pull scan has been 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.

[0064] 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, only the PC 40 that has received the instruction to start the scan accepts the cancel instruction for the scan job based on that instruction. Therefore, when the pull scan is executed, only the cancel instruction by PC operation can be transmitted 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 gave 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), which will be described later (S91).

[0065] Next, the processing when an error occurs after the pull scan is started and a cancel 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 cancel 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 cancel 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 cancel instruction for PC operation. Note that the controller 11 may be configured to immediately terminate the scan job when an event that requires immediate termination of the scan job, such as a serious error, occurs.

[0066] Next, the processing when a cancel 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 cancel 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).

[0067] When the function "SFL" is invalid (S51: NO in Fig. 7), or when the function "SFL" is valid (S51: YES) and there is no restriction on the function "Scan" in "Public Mode" (S53: NO), a negative determination is made at 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 (true) indicating success is not set in the authentication completion flag. In this case, the controller 11 makes a negative determination at S112 (S112: NO), executes S114, sets a value indicating permission to cancel the scan job in the job cancellation flag, and ends the process of Fig. 15. The controller 11 refers to the job cancellation flag (S102), and since the job cancellation flag referred to at S102 is a value indicating permission (S103: YES), it executes the job cancellation process shown in Fig. 12 (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).

[0068] On the one hand, when the function "SFL" is valid (S51: YES), the restriction of the function "scan" is set in "Public Mode" (S53: YES), and the user authentication information received 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 (true) indicating success (S62). In this case, the controller 11 makes an affirmative determination in S112 (S112: YES) and executes S115. In S115, the controller 11 determines whether it is in the logged-in state. When the MFP 10 is in the logged-out state (S115: NO), a value indicating that job cancellation (cancellation instruction by user IF operation) is not permitted is set in the job cancellation flag (S116), and the process of FIG. 15 ends. The controller 11 returns to the process of FIG. 14, makes a negative determination in S103 (S103: NO), and continues to execute the scan job by the scanner 15 without canceling the scan job (S105). The controller 11 resumes the output of scan data, etc. 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, the controller 11 executes S8. When the scan job is not canceled (S8: NO), that is, when S105 is executed, the process from S3 is executed again. The scan job of the push scan continues without being canceled. If there is no cancellation instruction for the scan job during the continued scan, the controller 11 completes the scan (S3: YES). When a cancellation instruction is received again (S5: YES), it is determined again whether to permit the execution of cancellation (S6). Also, the process from S3 is executed again. If the scan is not completed (S3: NO), S4 is executed, and it is determined that an error has occurred. Note that the controller 11 does not necessarily have to temporarily stop the execution of the scan job when making an affirmative determination in S5. In this case, the process of S105 can be omitted.

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

[0070] 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 completely match. However, in this specification, the correspondence of the user authentication information does not necessarily mean that the user names completely 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 match of the user names, 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.

[0071] 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 recognized as being able 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 a user IF operation while logged in after the pull scan has 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).

[0072] Then, when the logged-in user is not an administrator (S125: YES), the controller 11 sets a value indicating non - permission to cancel the job in the job cancellation flag (S126), and ends the process shown in FIG. 16. Since the job cancellation flag has a value indicating non - permission (S103: NO), the controller 11 continues to execute the pull scan job without cancelling it (S105). 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 cancelled by the operation of a user different from the user who gave the start instruction operation of the pull scan.

[0073] While the scan is in progress, the scanning-in-progress screen 69 shown in Fig. 17(e) is being displayed. Therefore, when the authentication of the user authentication information sent from the PC 40 is successful and the pull scan is started while the MFP 10 is in the logged-out state, the user cannot operate the standby screen 60 in Fig. 17(a) to log in. Also, when the authentication of the user authentication information sent from the PC 40 is successful and the pull scan is started while the MFP 10 is in the logged-in state, the user cannot operate the standby screen 60A in Fig. 17(d) to log out or change the logged-in user. Therefore, while the pull scan is in progress, by displaying the scanning-in-progress screen 69, it is restricted for a user other than the user who gave the start instruction for the pull scan to log out the MFP 10 or change to a new logged-in state via the standby screen 60 or the standby screen 60A in order to operate the MFP 10.

[0074] Also, even if for some reason the MFP 10 is logged out or a new logged-in state is entered during the pull scan, the scan job of the pull scan started by successfully authenticating the user authentication information sent from the PC 40 can be restricted from being cancelled by the operation of a user other than the user who gave the start instruction for the pull scan by the processing described with reference to Figs. 11 to 16.

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

[0076] In the present embodiment described above, the following effects can be achieved. After the controller 11 of the MFP 10 starts the pulse scan, when a cancel instruction to cancel the scan job is received via the user IF 16 (S5: YES), if the user authentication information received via the user IF 16 matches the user authentication information received together with the execution instruction of the pulse scan (S122: NO), the pulse scan is canceled (S123), and if they do not match, it is not canceled (S122: YES, S126). Thus, when the user who instructed the execution of the pulse scan gives a cancel instruction for the scan job via the user IF 16, cancellation is permitted, but when another user gives a cancel instruction, cancellation is not allowed, so that the appropriate user can execute the cancellation.

[0077] Also, when the controller 11 receives a cancel instruction in the logged-in state (S115: YES), 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 pulse scan (S122: NO), the pulse scan is canceled (S123), and if they do not match, it is not canceled (S122: YES, S126). Thus, when the user who instructed the execution of the pulse scan matches the logged-in user logged in to the MFP 10, cancellation can be permitted. For example, the user can cancel by operating the cancel key of the user IF 16 when he / she wants to cancel after logging in in advance and moving to his / her own PC 40 and then executing the pulse scan.

[0078] Also, in the logged-in state, in response to receiving an execution instruction for a pulse scan together with user authentication information (S34), if the logged-in user's user authentication information matches the user authentication information of the execution instruction (S72: NO), the controller 11 starts the pulse scan (S76); if they do not match (S72: YES), the controller 11 does not start the pulse scan (S73). After the controller 11 starts the pulse scan with the logged-in state and the user authentication information matching, if a cancel instruction is received at the user IF 16 while remaining logged in, and if the user authentication information of the logged-in user matches the user authentication information of the cancel instruction (S122: NO), the controller 11 cancels the scan. Thus, if the user operates the user IF 16 to log in with their own user name before executing the pulse scan, the logged-in state is maintained, so that after starting the pulse scan from the PC 40, the user can appropriately issue a cancel instruction at the user IF 16.

[0079] Also, after the logged-in user and the user indicated by the user authentication information of the execution instruction for the pulse scan match and the controller 11 starts the pulse scan, the controller 11 displays the scan execution screen 69 shown in FIG. 17(e). Therefore, after the start of the pulse scan, until the pulse scan is terminated or canceled, the controller 11 does not accept a logout operation or a user change operation. 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 cancel instruction. Also, it is possible to suppress a change in the logged-in user and a situation where the user authentication information of the logged-in user does not match the user authentication information of the execution instruction.

[0080] Also, when the controller 11 receives a cancel instruction in the logged-in state, even if the user authentication information of the logged-in user does not match the user authentication information of the execution instruction for the pulse scan (S122: YES), if the user authentication information of the logged-in user is the user authentication information of the administrator (S125: NO), the controller 11 cancels the pulse scan (S123). Thus, the administrator can cancel the pulse scan of each user by logging in. With the administrator's authority, unnecessary scan jobs can be canceled.

[0081] Also, after starting the pulse scan, when the controller 11 receives a cancel instruction in the logged-out state (S115: NO), it does not cancel the pulse scan (S116). This makes it possible not to cancel even if a cancel instruction is issued in the "Public Mode" state. It can prevent users other than the user who issued the execution instruction from canceling.

[0082] Also, when the controller 11 successfully authenticates the user authentication information received together with the execution instruction of the pulse scan (S61: YES, S72: NO), and after starting the pulse scan, receives a cancel instruction via the user IF16 in the logged-out state (S115: NO), it does not cancel the pulse scan (S116). Therefore, when user authentication is required (S33: YES), and authentication is successful (S37: YES), and the pulse scan is started (S40), it is not canceled in the logged-out state. This can prevent others from canceling the pulse scan.

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

[0084] Also, after the controller 11 starts push scanning in the logged-in state, if a cancel instruction is received while remaining in the logged-in state (S86: NO), it cancels regardless of the user authentication information of the logged-in user (S91). When an execution instruction for push scanning is executed in the logged-in state and a cancel instruction is executed while remaining in the logged-in state, it is highly likely that the user who issued the execution instruction and the cancel instruction is the same user. Therefore, even in such a case, by canceling without confirming the identity of the user authentication information, user usability can be improved.

[0085] Also, when the controller 11 receives an execution instruction for push scanning in the logged-in state, if the authority of the logged-in user is the authority that permits push scanning (S27: YES), it instructs the scanner 15 to start scanning (S29). Also, when the controller 11 receives an execution instruction for pull scanning in the logged-in state, if the user authentication information matches (S72: NO) and the authority of the logged-in user is the authority that permits push scanning (S75: YES), it starts pull scanning (S76). Thereby, based on the restriction of "scan" in the function designation column 33 shown in FIG. 2, that is, the restriction setting value of push scanning, the execution authority of pull scanning can be determined.

[0086] Also, after the controller 11 starts pull scanning, if it receives a cancel instruction from the transmission source (PC40) of the execution instruction for pull scanning (S93: YES), it cancels the pull scanning without the need to receive user authentication information via the user IF16 (S96). The controller 11 does not receive a cancellation of the started pull scanning from outside the PC40 of the instruction source. In other words, when a cancel instruction is received after the start of pull scanning, 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 the user authentication information and permitting cancellation, user usability can be improved. Note that the user authentication information may also be confirmed in this case.

[0087] 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 does not require user authentication information and starts a pull scan (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 receiving a cancel instruction by a user IF operation, the controller 11 does not request user authentication information (S112: NO) and cancels the pull scan (S114). Thereby, when user authentication is not required for an execution instruction of a pull scan, user authentication is also not required for execution of cancellation, improving usability for the user.

[0088] Also, the controller 11 determines whether an error has occurred in the MFP 10 (S4, S94). After starting a pull scan (S86: YES), when the controller 11 determines that an error has occurred (S94: YES), in canceling the pull scan, the controller 11 does not request user authentication information and cancels the pull scan (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 memory full occurs after starting a 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 the transmission of scan data in which a read error has occurred. In other words, even if an error occurs, the scan job can be continued as much as possible, such as continuing to transmit the created scan data until the user instructs cancellation. When, for example, a jam in the ADF is regarded as an error occurrence, the user can select to give a cancel instruction or to remove the error event and continue the scan job, for example, by removing the jam in the ADF.

[0089] (Modification Example of 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, the push scan in the logged-out state (S53: YES), the controller 11 requires user authentication in the pull scan. Instead of this, if the restriction setting value "restriction" is registered in the SFL database 19 referred to in S52 for the function "scan" corresponding to all registered users (S53: YES), the controller 11 may require user authentication in the pull scan. Furthermore, if the restriction setting value "restriction" is registered in the SFL database 19 referred to in S52 for the function "scan" by a predetermined specific user (S53: YES), the controller 11 may require user authentication in the pull scan.

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

[0091] 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 succeeded in user authentication. In S75, if the controller 11 determines that the limit setting value "restriction" is registered in the SFL database 19 for the function "scan" by the user who has succeeded in user authentication (S75: YES), it proceeds to S73 and does not permit the start of the scan process (pull scan). On the other hand, if the controller 11 determines that the limit setting value "permission" is registered in the SFL database 19 for the function "scan" by the user who has succeeded in user authentication (S75: NO), it proceeds to S76 and permits the start of the pull scan.

[0092] (Other Embodiments) The reading device is not limited to the above-described embodiments, and various modifications are possible without departing from the spirit thereof. The order, content, etc. of the processes shown in FIGS. 3 to 16 in the above-described embodiments are examples. For example, in the above-described embodiments, the controller 11 confirms the registration of the pull scan user in S36 (S61), determines in S71 and S72 whether the registered user matches the logged-in user, and if they match (S72: NO), permits the execution of the pull scan. However, the controller 11 may only confirm the registration of the user in S36 (S61) and 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. Further, after starting push scanning in the logged-in state, if the controller 11 receives a cancel instruction while remaining in the logged-in state, it may again request the input of the login user's password, and cancel the push scanning when the input password matches the input of the login user's password. Further, 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. Further, 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 has been received, the cancel control processing in S95 is executed. Further, while the controller 11 is displaying the scan execution screen 69, it may receive a login operation by an administrator by receiving a predetermined operation on the user IF 16. Thereby, even during scan execution, the administrator can log in and cancel.

[0093] 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. However, authentication and function restriction may be performed 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 (Lightweight Directory Access Protocol) server. Further, the controller 11 may perform restriction of functions 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. Further, 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.

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

Explanation of symbols

[0095] 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, and the controller is capable of starting the pull scan in response to receiving the execution instruction for the pull scan together with user authentication information, and the controller is configured such that, after starting the pull scan, if a cancellation instruction is received via the user interface, the pull scan is cancelled 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, and is not cancelled if it does not correspond, a reading device.

2. The controller according to claim 1, wherein the controller is configured such that, after starting the pull scan, if a cancellation instruction is received via the user interface while logged in, the pull scan is cancelled if the user authentication information of the logged-in user previously received by a login operation via the user interface corresponds to the user authentication information received together with the execution instruction for the pull scan, and is not cancelled if it does not correspond.

3. The controller, wherein, in a logged-in state, in response to receiving the execution instruction for the pull scan together with the user authentication information, the pull scan is started if the user authentication information of the logged-in user corresponds to the user authentication information received together with the execution instruction for the pull scan, and is not started if it does not correspond, and the controller is configured such that, after starting the pull scan because the user authentication information of the logged-in user corresponds to the user authentication information received together with the execution instruction for the pull scan, if a cancellation instruction is received via the user interface while remaining logged in, the pull scan is cancelled if the user authentication information of the logged-in user corresponds to the user authentication information received together with the execution instruction for the pull scan, and is not cancelled if it does not correspond, the reading device according to claim 2.

4. The controller, 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, the reading device according to claim 3 is configured not to accept a logout operation via the user interface until the pull scan is terminated or canceled.

5. The controller After starting the pull scan, when a cancel instruction is received via the user interface while 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 pull scan, the pull scan is canceled; if not, it is not canceled, and is configured as such. The controller Even when the user authentication information of the logged-in user, which was previously accepted by a login operation via the user interface, does not correspond to the user authentication information received together with the execution instruction of the pull scan, if the user authentication information of the logged-in user corresponds to the user authentication information of an administrator, the pull scan is canceled, and the reading device according to claim 2 is configured as such.

6. The controller In response to receiving the execution instruction of the pull scan together with user authentication information, after starting the pull scan, when a cancel instruction is received via the user interface while not logged in, the reading device according to claim 1 or claim 2 is configured not to cancel the pull scan.

7. The controller After receiving the execution instruction of the pull scan together with user authentication information and succeeding in authenticating the received user authentication information, when a cancel instruction is received via the user interface while not logged in after starting the pull scan, the reading device according to claim 6 is configured not to cancel the pull scan.

8. The controller is capable of executing a push scan for causing the scanner to read a document according to an execution instruction corresponding to an operation on the user interface. The controller In response to receiving an execution instruction for the push scan via the user interface, it is possible to start the push scan. The controller when receiving the cancel instruction via the user interface if the cancel instruction via the user interface is received after the start of the pull scan, and 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 pull scan is canceled; if not, it is not canceled. It is configured as such. The controller 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 is configured as such.

9. The controller in a logged-in state, in response to receiving an execution instruction for the push scan via the user interface, it is possible to start the push scan. The controller when receiving the cancel instruction via the user interface if the user authentication information of the logged-in user corresponds to the user authentication information received together with the execution instruction for the pull scan and the pull scan is started, and then it is received 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 for the pull scan, the pull scan is canceled; if not, it is not canceled. after starting the push scan in a logged-in state and then received while remaining logged in, it is configured to cancel regardless of the user authentication information of the logged-in user. The reading device according to claim 8 is configured as such.

10. The controller In response to receiving an execution instruction for the push scan via the user interface while logged in, if the authority of the logged-in user is the authority that permits the push scan, the push scan is started; if not, it is not started. The controller In response to receiving an execution instruction for the pull scan together with the user authentication information while logged in, if the user authentication information of the logged-in user corresponds to the user authentication information received together with the execution instruction for the pull scan, and if the authority of the logged-in user is the authority that permits the push scan, the pull scan is started; if not, it is not started. The reading device according to claim 9.

11. The controller is also configured to be able to receive the cancel instruction from the source that sent the execution instruction for the pull scan. The controller when the cancel instruction is received after the start of the pull scan if the cancel instruction is received via the user interface, the pull scan is canceled 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; if not, it is not canceled. if the cancel instruction is received from the source that sent 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. The reading device according to claim 1 or claim 2.

12. 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 the cancel instruction is received after starting the pull scan If the pull scan has been started in response to receiving the execution instruction for the pull scan together with the user authentication information, and 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, then cancel the pull scan; if not, do not cancel it. The reading device according to claim 1 or claim 2, which is configured such that, if the pull scan has been started in response to receiving the execution instruction for the pull scan without requiring the user authentication information, the pull scan is cancelled without the need to receive the user authentication information via the user interface. **Claim 13** The controller is configured to be able to determine whether an error has occurred in the reading device. The controller is configured such that, if it determines that an error has occurred in the reading device after starting the pull scan, the pull scan is cancelled without the need to receive the user authentication information via the user interface. The reading device according to claim 1 or claim 2.

Images