Reader

Abstract

The objective is to provide a reader device that improves usability in authentication associated with pull scanning. [Solution] When the MFP10's controller 11 receives a pull scan execution instruction from the PC40, if the MFP10 is logged in (S57:YES), and if the user authentication information included in the pull scan execution instruction corresponds to the user authentication information of the logged-in user (S67:YES), the controller 11 executes the pull scan (S63). If the two sets of user authentication information do not correspond, the controller 11 restricts the pull scan (S64). Also, when the controller 11 receives a pull scan execution instruction from the PC40, if the MFP10 is not logged in (S57:NO), the controller 11 does not require the two sets of user authentication information to correspond (S55) and executes the pull scan.

Description

Technical Field

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

Background Art

[0002] Patent Document 1 describes a reading device capable of executing a pull scan for causing a scanner to read a document according to an execution instruction from an external device. The reading device of Patent Document 1 performs authentication using a user ID and a password included in an execution instruction of a pull scan of an external device. When the authentication is successful, the reading device executes a pull scan to generate scan data and transmits the generated scan data to the external device.

Prior Art Documents

Patent Documents

[0003]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0004] In the reading device of Patent Document 1, there is room for improvement in the method of authentication associated with the execution of a pull scan.

[0005] The present invention has been made in view of the above problems, and an object thereof is to provide a reading device capable of improving user-friendliness in authentication associated with the execution of a pull scan.

Means for Solving the Problems

[0006] To solve the above problems, the reading device disclosed in this embodiment is a reading device comprising a user interface, a scanner, and a controller, wherein the controller is capable of performing a push scan, which causes the scanner to read a document based on an execution instruction corresponding to an operation on the user interface, and a pull scan, which causes the scanner to read a document based on an execution instruction from an external device, and when the reading device is logged in, the controller is configured to perform the pull scan if the user authentication information included in the pull scan execution instruction corresponds to the user authentication information of the logged-in user, and to restrict the pull scan if the user authentication information included in the pull scan execution instruction does not correspond to the user authentication information of the logged-in user, and when the reading device is not logged in, the controller is configured to perform the pull scan without requiring a correspondence between the user authentication information included in the pull scan execution instruction and the user authentication information of the logged-in user.

[0007] In the above configuration, a user performing a pull scan from an external device can require authentication to execute the pull scan by logging into the reader. This restricts other users from performing pull scans. Furthermore, if the user performing the pull scan from an external device determines that authentication is unnecessary, they can log out the reader and send a pull scan command, thereby executing the pull scan without performing authentication using user authentication information. Therefore, even users who are not administrators of the reader can switch between requiring or not requiring user authentication to execute a pull scan. This improves usability in the authentication process associated with executing pull scans. [Effects of the Invention]

[0008] According to the present invention, usability can be improved in authentication associated with pull scanning. [Brief explanation of the drawing]

[0009] [Figure 1] This is a diagram of the MFP configuration. [Figure 2] This is a diagram showing the restriction settings screen. [Figure 3] This flowchart shows the scan control process performed by the MFP controller. [Figure 4] This is a flowchart showing the process executed in S2 of Figure 3. [Figure 5] This is a flowchart showing the process executed in S11 of Figure 4. [Figure 6] This is a flowchart showing the process executed in S12 of Figure 4. [Figure 7] This is a flowchart showing the process executed in step S32 of Figure 6. [Figure 8] This is a flowchart showing the process executed in S36 of Figure 6. [Figure 9] This is a flowchart showing the process executed in S38 of Figure 6. [Modes for carrying out the invention]

[0010] An embodiment of the reading device will be described using an MFP (Multi Function Peripheral). As shown in Figure 1, the MFP 10 includes a controller 11, memory 12, printer 13, FAXIF 14, scanner 15, user IF 16, USBIF 17, and communication IF 18. These components are connected to each other via bus 1 so that they can communicate with one another.

[0011] The printer 13 prints images onto a recording medium such as a sheet or a disc. The sheet can be, for example, paper or an OHP sheet. The printer 13 can employ an inkjet method or an electrophotographic method for printing. The scanner 15 has a reading sensor, such as a CCD or CIS, and generates image data corresponding to the reading of the original document.

[0012] User IF16 is an interface that can accept various operations on the MFP10. User IF16 includes a touch panel with an LCD display and various operation keys. USBIF17 allows for the detachable connection of storage media compliant with the USB standard, and enables data reading and writing via communication compliant with the USB standard. Storage media compliant with the USB standard include, for example, USB memory sticks. The MFP10 is connected to a network via Communication IF18 and communicates with the PC40 via the network according to a predetermined protocol (such as TCP / IP). Communication IF18 can be a wired LAN interface, a wireless LAN interface, or the like.

[0013] The controller 11 is a processing unit that includes, for example, a CPU. The memory 12 is composed of a combination of volatile memory such as RAM, non-volatile memory such as NVRAM, and ROM. SSDs and HDDs may be used as non-volatile memory. Buffers provided by the controller 11, used when various programs are executed, may also be considered part of the memory 12. The memory 12 may also be a storage medium that the controller 11 can read. A storage medium that the controller 11 can read is a non-transitory medium. In addition to the examples above, non-transitory media also include recording media such as CD-ROMs and DVD-ROMs. Non-transitory media are also tangible media. On the other hand, electrical signals that carry programs downloaded from servers on the internet are a type of computer-readable signal medium, but they are not included in non-transitory computer-readable storage media.

[0014] Memory 12 stores control program 2 as a program that controller 11 can execute. Control program 2 is, for example, firmware that comprehensively controls each part of MFP 10. Controller 11 controls each device connected to bus 1 by executing control program 2. In this embodiment, the processing of controller 11 according to the instructions written in the program is mainly shown. That is, processes such as "judgment," "identification," "acquisition," and "restriction" in the following description represent processing of controller 11. Note that "acquisition" is used as a concept that does not necessarily require a request. That is, the process of controller 11 receiving data without a request is also included in the concept of "controller 11 acquiring data." Also, "data" in this specification is represented by a bit sequence that controller 11 can read. Data that has the same substantial meaning but a different format is treated as the same data. The same applies to "information" in this specification.

[0015] Furthermore, control program 2 includes, for example, an EWS (Embedded Web Server) program, which functions as a web server. Controller 11 can make MFP 10 function as a web server by executing the EWS program. The web server functioning in MFP 10 is also referred to as EWS. Controller 11 can display a specified web page in the browser 41 of PC 40 (described later) by sending web page data to PC 40. Sending web page data is also referred to 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 display a web page on the display according to the web page data transmitted from the MFP 10. 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 pulse scan 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 this embodiment has a "Secure Function Lock" function (hereinafter sometimes referred to as the function "SFL"). The function "SFL" is a function that sets whether to permit each function of the MFP 10 for each user and restricts the execution of functions set not to be permitted. Setting not to permit each function of the MFP 10 is also described as restricting. The controller 11 receives, for example, setting values regarding the enable / disable of the function "SFL", user registration, password registration, and function restriction for each user through 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 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 through the EWS, and a method of receiving through the user IF 16 may also be used.

[0018] FIG. 2 shows a restriction setting screen 30 for receiving functions restricted for each user. The controller 11 provides a web page to the browser 41 of the PC 40 that has accessed the EWS, for example. When an administrator login operation is performed on the provided web page, the controller 11 provides the PC 40 with a web page for setting the enable / disable of the function "SFL" 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 user and function to be restricted in the function "SFL". The restriction specification field 31 has a user specification field 32 (32A, 32B) for specifying the user to be restricted and a function specification field 33 for specifying whether to permit or not permit each function. There are a plurality of user specification fields 32. Among the user specification fields 32, the "Public Mode" 32A is a field indicating that the target of the function "SFL" 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 a restriction without specifying a user. The individual user field 32B is a field for inputting the user name indicating the user targeted by the function "SFL". That is, it can also be said that it is a field indicating setting a restriction 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 function corresponding to the user indicated by the user specification field 32.

[0020] Function specification field 33 is also a field where you can specify which functions are restricted by the function "SFL". Function specification field 33 has checkboxes to indicate whether or not restrictions are set for each of the MFP10's functions: "Print", "Copy", "Scan", "FAX", "USB", and "Web Connection". Note that the function "Scan" corresponds to push scan and pull scan, which will be described later. In function specification field 33, a checked function is a function that is not restricted, i.e., the execution of the function is permitted, and an unchecked function is a function that is restricted, i.e., the execution of the function is not permitted. In addition, the function "FAX" includes the individual functions "Send FAX" and "Receive FAX", and there is a checkbox for each individual function. The function "USB" includes the individual functions "USB Direct Print" and "Scan to USB", and there is a checkbox for each individual function. "Web Connection" includes the individual functions "Upload" and "Download", and there is a checkbox for each individual function. In the following section 33 of the function specification column, a checked checkbox for each function is referred to as "allowed," while an unchecked checkbox is referred to as "restricted."

[0021] In the example shown in Figure 2, the function specification field 33 of "Public Mode" 32A has the "Scan" function unchecked, while all other functions are checked. In this case, when no one is logged into the MFP10 (logout state), the execution of the "Scan" function is restricted, while the execution of other functions is not restricted. Similarly, for "User A" and "User B" in the individual user field 32B, each function is restricted or not restricted depending on the checked items. For convenience, "restricted or not restricted" may be abbreviated to "restricted." When the "SFL" function is enabled and any user is logged in (hereinafter sometimes referred to as the logged-in state), the controller 11 restricts functions based on the settings of the logged-in user. Furthermore, when the instruction from the PC 40 requires authentication, the controller 11 restricts functions based on the settings of the authenticated user. When the OK button (not shown) is operated, the controller 11 updates each setting in the SFL database 19 based on the input to the restriction setting screen 30.

[0022] Furthermore, the controller 11 stores and utilizes various settings in memory 12, not just the SFL database 19. The act of storing settings in memory 12 is sometimes referred to as "setting," and the fact that settings are stored in memory 12 is sometimes referred to as "being set," "being configured," or "being configured," for convenience.

[0023] Next, the procedure for processing performed by the controller 11 when a user utilizes the "Scan" function of the MFP 10 will be explained. The MFP 10 can perform "Push Scan" and "Pull Scan" as part of its "Scan" function. The controller 11 generates scan data using image data output by the scanner 15 when it reads a document. Scan data is also a type of image data. "Push Scan" is a scan in which, in response to an execution instruction given by the user IF 16, the scanner 15 reads a document to generate scan data, and the generated scan data is output to an output destination corresponding to the execution instruction, for example, by transmitting the scan data. The output destination for data from a push scan can be a PC 40, a device connected to the MFP 10, for example, a device connected via USBIF 17 or communication IF 18. "Pull Scan" is a scan in which, in response to an operation on an external device, the scanner 15 reads a document to generate scan data in response to an execution instruction sent from the external device, and the generated scan data is sent to the device that sent the execution instruction. In this embodiment, the external device is a PC 40.

[0024] Controller 11 does not restrict either the "push scan" or "pull scan" scan functions if the checkbox for the function "Scan" in the function specification column 33 of Figure 2 is checked and the restriction setting value is "Allowed". If the restriction setting value is "Restricted", both scan functions are restricted. As will be explained in more detail later, the method of restricting the scan functions may differ between "push scan" and "pull scan". Note that the types and configuration of items shown in Figure 2 are just examples. For example, the function specification column 33 shown in Figure 2 may have separate checkboxes for "push scan" and "pull scan". Controller 11 may also be configured to allow individual settings for each of the two checkboxes to determine whether or not to restrict the "push scan" and "pull scan" scan functions, respectively.

[0025] Furthermore, the MFP10 can execute a "first pull scan method" and a "second pull scan method" as methods for executing a "pull scan". When the first pull scan method is set, the controller 11 decides whether or not to require user authentication to execute a pull scan, depending on whether the restriction setting value corresponding to the "scan" function in the logout state is "restricted", that is, depending on whether or not the checkbox for the "scan" function in the function specification field 33 of "Public Mode" 32A is checked. If the first pull scan method is set and the restriction setting value corresponding to the "scan" function in "Public Mode" 32A is "restricted", the controller 11 requires user authentication to execute a pull scan, and does not require user authentication if the restriction setting value is "allowed". As described above, in this embodiment, the two scan functions, "push scan" and "pull scan", are set with one checkbox in the function specification field 33. For this reason, the "restriction setting value for push scan restrictions" in this specification is the same setting as the "restriction setting value for pull scan restrictions", and is changed depending on whether or not the checkbox for the scan function is checked.

[0026] Furthermore, as mentioned above, the configuration may allow for individual settings using two checkboxes to determine whether or not to restrict the two scanning functions, "push scan" and "pull scan." The controller 11 may, for example, when the first pull scan method is set, not require user authentication to perform a pull scan if the "pull scan" checkbox in "Public Mode" 32A is checked and the restriction setting is "allowed," nor require user authentication to perform a pull scan if the "pull scan" checkbox is unchecked and the restriction setting is "restricted."

[0027] Furthermore, when the second pull scan method is set, the controller 11 decides whether or not to require user authentication to perform the pull scan, depending on whether or not the MFP 10 is logged in. If the second pull scan method is set and the user is logged in, the controller 11 requires user authentication to perform the pull scan; if the user is logged out, it does not require user authentication.

[0028] As shown in Figure 2, the upper part of the restriction setting screen 30 is provided with radio buttons 34 for setting the first pull scan method and radio buttons 35 for setting the second pull scan method. When either radio button 34 or radio button 35 is selected and the OK button (not shown) is operated, the controller 11 stores the information selected by radio buttons 34 and 35 in, for example, the SFL database 19. Based on the information in the SFL database 19, the controller 11 performs user authentication for the pull scan using the method checked by radio buttons 34 and 35. Figure 2 shows the state in which the first pull scan method is set. Note that the method for changing the settings of the first and second pull scan methods is not limited to the method using radio buttons as shown in Figure 2, but may also be other methods, such as using a pull-down menu. Also, the method for changing the settings of the first and second pull scan methods is not limited to receiving the information via EWS, but may also be received via the user IF 16.

[0029] Controller 11 starts the scan control process shown in Figure 3, for example, after the MFP 10 is powered on and the control program 2 is executed to start the system. Note that the conditions for starting the process in Figure 3 are not limited to the conditions for starting the system. For example, Controller 11 may start the process in Figure 3 when it returns from a power-saving mode that reduces power consumption. In the following explanation, we will first assume that the limit settings shown in Figure 2 are configured in the SFL database 19.

[0030] First, in step 1, the controller 11 determines whether or not it has received a command to execute a scan. Hereafter, steps will be referred to as "S". The controller 11 executes the process in S1 until it determines that it has received a command to execute a push scan or pull scan (S1:NO), and if it determines that it has received the command (S1:YES), it executes the scan request process in S2.

[0031] As shown in Figure 4, in S10, the controller 11 determines whether or not it has received an instruction to execute a push scan. Specifically, if the controller 11 receives an instruction to start the "scan" function through an operation on the user IF16 of the MFP10, it determines that it has received an instruction to execute a push scan (S10: YES) and executes the push scan request processing in S11. For example, in response to receiving an operation on the user IF16, the controller 11 sends a push scan request to an external device (PC40 in this example). The external device that receives the request replies to the MFP10 with an instruction to execute "scan". When the controller 11 receives this reply, it determines that it has received an instruction to execute a push scan. Also, if the controller 11 has performed an operation to start a scan on the external device and has received an execution instruction sent from the external device, it determines that it has received an instruction to execute a pull scan (S10: NO) and executes the pull scan request processing in S12.

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

[0033] As shown in Figure 5, in S11, the controller 11 either restricts or does not restrict push scanning according to the restriction setting value registered in the SFL database 19. First, the processing in the logout state will be explained. For convenience, the logout state in which no one is logged into the MFP 10 is also referred to as "Public Mode". For example, the SFL database 19 stores information indicating whether the function "SFL" is enabled "ON" or disabled "OFF" (hereinafter, this may be referred to as function "SFL" information). In S21, the controller 11 determines the function "SFL" information of the SFL database 19 stored in memory 12. If the controller 11 determines that the function "SFL" information indicates that it is disabled (S21: NO), it executes S29 and instructs the scanner 15 to start scanning in order to read the document placed on the document glass. That is, the controller 11 executes the processing without imposing any restrictions on push scanning and finishes the processing shown in Figures 3 to 5.

[0034] In this example, it is assumed that the function "SFL" in the SFL database 19 is set to "ON" and enabled. Therefore, the controller 11 determines that the function "SFL" is enabled (S21:YES). In S23, the controller 11 checks whether the user IF16 is logged in through an operation, and in this example, the user is logged out (S23:NO). Therefore, the controller 11 refers to the restriction setting value in the SFL database 19 that corresponds to the function "Scan" in "Public Mode" (S24).

[0035] As shown in Figure 2, the controller 11 notifies an error indicating that the "Scan" function cannot be executed because the restriction setting value corresponding to the "Scan" function in "Public Mode" is "Restricted" (S25: YES) (S28). In this embodiment, the controller 11 notifies the user IF 16 by displaying an error screen indicating that the "Scan" function cannot be executed. That is, the controller 11 has set a restriction on push scanning when logged out. In this embodiment, the restriction on the "Scan" function is that the scan process is not executed. Alternatively, the restriction on the "Scan" function could be configured to reduce the quality of the scan performed. Alternatively, the restriction on the "Scan" function could be configured to require an additional special permission operation by an administrator to execute the scan. The controller 11 terminates the processing shown in Figures 3 to 5. If the restriction setting value corresponding to the "Scan" function in "Public Mode" were "Allowed" (S25: NO), the controller 11 instructs the scanner 15 to start scanning (S29).

[0036] Next, we will explain the process when "User A" is logged into MFP10. Since "User A" is logged in (S23:YES), Controller 11 checks the restriction setting value corresponding to the "Scan" function for User A in S26. As shown in Figure 2, the restriction setting value corresponding to the "Scan" function for "User A" is set to "Restricted," so Controller 11 makes a positive judgment in S27 (S27:YES), notifies the previously explained error indicating that the scan cannot be executed (S28), and terminates the process shown in Figures 3 to 5. If "User B" is logged in, the restriction setting value "Allowed," which does not restrict the "Scan" function, is registered for "User B" in SFL database 19 (S27:NO, see Figure 2), so the scan process starts (S29).

[0037] Here, we will explain login. The SFL database 19 contains user authentication information for "User A" and "User B". The registered user authentication information consists of a user ID and a password corresponding to the user ID. When the controller 11 receives a user ID and a password corresponding to the user ID from the SFL database 19 via the user IF 16 during the login process, the MFP 10 performs various operations as if it has entered the login state corresponding to the entered user authentication information. For example, when user ID "User A" and a corresponding password are entered, the controller 11 performs various operations as if the MFP 10 has entered the login state corresponding to the entered "User A". The user authentication information registered in the SFL database 19 can also be said to be the user authentication information of users who are permitted to log in to the MFP 10. The login state corresponding to the user authentication information is also referred to as the state in which the user indicated by the user authentication information is logged in. Furthermore, the login state corresponding to "User A" is also referred to as the state in which "User A" is logged in. In addition, when the user indicated by the user authentication information is logged in, the user indicated by the user authentication information is also referred to as the "logged-in user". Furthermore, the input of the user ID and password during the login process may be performed by bringing the ID card corresponding to the user ID registered in the SFL database 19 close to or touching it to the MFP 10. Also, the information used for the login process may be stored in an area of ​​memory 12 other than the SFL database 19. In this case, the controller 11 may refer to that area in memory 12 during the login process and in the process shown in Figure 8.

[0038] Next, we will explain the process that the controller 11 executes when it receives a pull scan execution instruction from the PC 40. First, we will explain the process when the first pull scan method is set. We will also explain the process when the MFP 10 is logged out, i.e., in "Public Mode", and "User A" operates the PC 40 to execute a pull scan. As shown in Figure 6, when the controller 11 starts the process in S12, it determines whether the execution of the pull scan is set to be enabled or disabled in the MFP 10 (S31). For example, the controller 11 makes this determination based on information stored in memory 12, separate from the SFL database 19, that indicates whether the pull scan is set to be enabled or disabled. In this example, assuming that the pull scan is set to be enabled (S31: YES), the controller 11 executes the user authentication requirement determination process in S32. Through this user authentication requirement determination process, the controller 11 determines whether user authentication is required for the pull scan execution instruction. Furthermore, if pull scan is disabled in MFP10 (S31:NO), controller 11 notifies PC40 that a pull scan cannot be performed (S41). In other words, if pull scan is disabled in MFP10, a pull scan will not be performed regardless of who is logged into MFP10.

[0039] As shown in Figure 7, when the controller 11 starts processing in S32, it refers to the function "SFL" information in the SFL database 19 and determines whether the function "SFL" is set to enabled or not (S50). In this example, since the SFL database 19 has information indicating that the function "SFL" is enabled (S50: YES), the controller 11 determines whether the first pull scan method is set or not (S51). In this example, since the first pull scan method is set (S51: YES), the controller 11 executes S52. In S52, the controller 11 refers to the limit setting value corresponding to the function "Scan" in "Public Mode" in the SFL database 19 (see Figure 2), and in S53, it determines whether the limit setting value indicates that scanning should be restricted or not.

[0040] In this example, as shown in Figure 2, the restriction setting value for the "Scan" function in "Public Mode" 32A is set to "Restricted" (S53: YES), so S54 is executed. In S54, the controller 11 sets that user authentication is required for the pull scan execution instruction. For example, the controller 11 sets a value indicating that user authentication is required in the necessity judgment flag, which is stored in memory 12 separately from the SFL database 19 and indicates whether or not user authentication is required.

[0041] Controller 11 executes S33 in Figure 6, and since the necessity determination flag is set to a value indicating that user authentication is required, i.e., user authentication is required (S33: YES), in S34, it communicates with PC 40 to request user authentication information necessary for user authentication. When PC 40 receives the request for user authentication information from MFP 10, it sends response data to MFP 10 that includes, for example, the user authentication information of the user operating PC 40. Specifically, the user authentication information is the user ID and password. This user authentication information is an example of the user authentication information included in the pull scan execution instruction in this specification. In this case, PC 40 sends response data that includes the user authentication information of "User A". PC 40 may also send response data that includes the user authentication information of the user logged into PC 40. Alternatively, PC 40 may send response data that includes the user authentication information entered by the user when logging into PC 40. Furthermore, after receiving the request for user authentication information, PC 40 may receive the user ID and password from the user and send them as response data.

[0042] After executing S34, the controller 11 determines whether or not it has received user authentication information from PC40 (S35). If PC40 does not send user authentication information in response to the request for user authentication information from MFP10, the user authentication process in S36, described later, cannot be executed. Therefore, if the controller 11 does not receive user authentication information from PC40 (S35: NO), it notifies PC40 in S41 that it cannot perform a pull scan.

[0043] Here, the controller 11 assumes that it has received user authentication information from the PC 40 (S35:YES) and executes the user authentication process in S36. As shown in Figure 8, when the controller 11 starts the process in S36, it determines whether the first pull scan method is set (S60). In this example, the first pull scan method is set (S60:YES), so the controller 11 executes S61. The controller 11 checks whether the user authentication information received from the PC 40 (in this example, information indicating user A) is registered in the SFL database 19 as information used for login processing (S61). As shown in Figure 2, the SFL database 19 has registered user authentication information for at least "user A" and "user B," that is, information indicating users who can log in to the MFP 10. The controller 11 determines that the user authentication information received from the PC 40, i.e., the user ID and password, is registered in the SFL database 19 (S62:YES), so it executes S63 and sets that user authentication was successful. For example, controller 11 sets the authentication completion flag, which indicates whether user authentication was successful or not, to a value indicating success (true). However, in S62, if the user authentication information received from PC 40 is not registered in the SFL database 19 (S62: NO), controller 11 sets the authentication completion flag to a value indicating user authentication failed (false) (S64). If a value indicating user authentication failed (false) is set, controller 11 determines in S37 of Figure 6 that user authentication has failed (S37: NO) and executes S41.

[0044] In this example, controller 11 determines in S37 of Figure 6 that user authentication is successful (S37:YES) and executes the scan permission confirmation process in S38. As shown in Figure 9, when controller 11 starts the process in S38, it determines whether the first pull scan method is set (S70). In this example, the first pull scan method is set (S70:YES), so controller 11 executes S71. Controller 11 determines whether the user is logged in, that is, whether it is in "Public Mode" (S71). In this example, it is in "Public Mode" (S71:NO), so controller 11 executes S75.

[0045] In S75, the controller 11 checks the restriction setting value for the "Scan" function for the user who successfully authenticated in S36, as described earlier. In this example, the "Scan" function corresponding to "User A" in the SFL database 19 has "Restricted" set as the restriction setting value (see Figure 2). Therefore, in S76, the controller 11 determines that there is a restriction on the "Scan" function (S76: YES), and in S74, sets the scan permission flag, which indicates whether or not to allow the start of a pull scan, to a value indicating that the start of a scan is not permitted.

[0046] In S39 of Figure 6, the controller 11 executes S41 because the scan permission flag is set to a value indicating that scanning is not permitted, i.e., scanning is not permitted (S39: NO). Since a push scan restriction is set for "User A", pull scans are restricted even if authentication by the user authentication process in S36 is successful. Then, the controller 11 terminates the process shown in Figure 6.

[0047] Next, we will explain the process when "User A" is logged into MFP10 and "User A" operates PC40 to perform a pull scan. In this example as well, the controller 11 performs the processes S31 to S37 in Figure 6, which have already been explained. In S32, the controller 11 identifies that push scans in "Public Mode" are restricted, and in S33, it determines that user authentication is required (S33: YES). Then, the controller 11 executes S38, provided that user authentication is successful (S37: YES).

[0048] In Figure 9, at S71, the controller 11 determines whether the user who requested the pull scan matches the logged-in user, since "User A" is logged in (S71: YES). Specifically, the controller 11 compares the user authentication information used in the user authentication process in S36, which was already explained, with the user authentication information of the logged-in user to determine whether the users match. In other words, the controller 11 determines whether the user who requested the start of the pull scan by operating the PC 40 matches the user logged into the MFP 10. Therefore, the user who requested the pull scan can also be said to be the user indicated by the user authentication information included in the pull scan execution instruction.

[0049] If controller 11 determines that the users match (S73: NO), it executes S75. In S75, controller 11 determines whether the "Scan" function is restricted for the user who successfully authenticated in S36. Controller 11 determines that the "Scan" function is restricted for user A who successfully authenticated in the SFL database 19 (S76: YES), and therefore executes S74, not allowing the start of the scan process (pull scan). Controller 11 executes S39 in Figure 6, and as already explained, the scan process is not permitted (S39: NO), so it executes S41.

[0050] Furthermore, if controller 11 determines in S73 of Figure 9 that the user does not match (S73: YES), it executes S74 and does not permit the start of the scan process (pull scan). Therefore, in Figure 6, controller 11 executes S41 because the scan process is not permitted (S39: NO).

[0051] Next, we will explain the process when "User B" operates PC40 and performs a pull scan while MFP10 is in "Public Mode" and not logged in. In this example as well, the controller 11 performs the processes S31 to S37 in Figure 6, which have already been explained. In S71 in Figure 9, the controller 11 is in "Public Mode" (S71: NO), and the restriction setting value corresponding to the function "Scan Processing" of "User B", who has successfully authenticated the user, is set to "Allow" (S76: NO). Therefore, in S77, the scan permission flag is set to a value indicating that the start of the scan is permitted. In S39 in Figure 6, the controller 11 has set the scan permission flag to a value indicating that the start of the scan is permitted (S39: YES), and, as in S29, instructs the scanner 15 to start scanning (S40). In other words, since there are no restrictions set on scanning for "User B", the controller 11 performs a pull scan on the condition that authentication is successful.

[0052] Next, we will explain the process when "User B" is logged into MFP10 and performs a pull scan. In this example as well, the controller 11 executes the processes S31 to S37 in Figure 6, which have already been explained. In S71 in Figure 9, the controller 11 determines that "User B" is logged in (S71:YES), and executes S72 to determine whether the user who requested the pull scan by operating PC40 matches the logged-in user of MFP10. If the controller 11 determines that the users match (S73:NO), it executes S75, and since the restriction setting value corresponding to the "Scan" function of "User B" is "Allowed" (S76:NO), it allows the pull scan to start (S77). Note that in S73 in Figure 9, if the controller 11 determines that the users do not match (S73:YES), it does not allow the pull scan to start (S74). In other words, even if user authentication is successful for "User B" and the restriction setting value corresponding to the "Scan" function for "User B" in the SFL database 19 is "Allowed," if the user requesting the pull scan does not match the logged-in user of MFP 10, the pull scan will not be allowed.

[0053] Next, unlike the example of the SFL database 19 shown in Figure 2, we will explain an example of performing a pull scan when the restriction setting value "Allowed" is set, which does not indicate any restrictions on the "Scan" function in "Public Mode". If the controller 11 makes an affirmative decision in S31 in Figure 6 (S31:YES), it executes S32, and in S50 in Figure 7, it finds that the function "SFL" is enabled "ON" in the SFL database 19 (S50:YES) and the first pull scan method is set (S51:YES), so it executes S52 and refers to the restriction setting value for the "Scan" function in "Public Mode". In this example, the restriction setting value "Allowed" is set for the "Scan" function in "Public Mode" in the SFL database 19 (S53:NO), so it executes S55. In S55, the controller 11 sets the necessity judgment flag to a value indicating that user authentication is not required for the push scan execution instruction. Then, in S33 of Figure 6, the controller 11 determines that user authentication is not required (S33: NO) and instructs the scanner 15 to start scanning (S40). In other words, in this example, scanning in "Public Mode" is not restricted, so pull scanning is not restricted for anyone.

[0054] Next, we will explain the process when the second pull scan method is set. In the following explanation, we will omit explanations of the same content as when the first pull scan method is set as described above. First, we will explain the process when MFP10 is logged out and "User A" operates PC40 to issue a command to execute a pull scan. In this example as well, the controller 11 executes the processes S31 and S32 in Figure 6, which have already been explained.

[0055] As shown in Figure 7, the controller 11 has the function "SFL" enabled (S50: YES) and the second pull scan method is set (S51: NO), so it executes S57 to determine whether the MFP 10 is logged in or not. When the second pull scan method is set, the controller 11 determines in the user authentication requirement determination process shown in Figure 7 whether or not to require user authentication for the pull scan execution command, depending on whether or not the MFP 10 is logged in or not. In this example, since the MFP 10 is logged out (S57: NO), the controller 11 sets the requirement determination flag in S55 to a value indicating that user authentication is not required for the pull scan execution. Then, in S33 in Figure 6, the controller 11 determines that user authentication is not required (S33: NO) and instructs the scanner 15 to start the scan (S40). In other words, in the second pull scan method, by putting the MFP 10 into a logged-out state, user authentication is not required for anyone to perform a pull scan. Therefore, even when MFP10 is logged out and "User B" performs a pull scan, user authentication is not required.

[0056] Next, we will explain the process when "User A" is logged into MFP10 and "User A" operates PC40 to issue a pull scan command. In this example as well, the controller 11 executes the processes S31 and S32 in Figure 6 and S50 and S51 in Figure 7, which have already been explained, and makes a negative judgment in S51 (S51: NO), and then executes S57. In this example, since the user is logged in (S57: YES), the controller 11 sets the necessity judgment flag in S54 to a value indicating that user authentication is required.

[0057] Controller 11 makes a positive determination in S33 of Figure 6 (S33: YES), requests user authentication information from PC 40 (S34), and determines whether or not it has obtained user authentication information from PC 40 (S35). When Controller 11 obtains response data containing user authentication information from PC 40 (S35: YES), it executes the user authentication process shown in Figure 8.

[0058] Furthermore, when the second pull scan method is set, the pull scan execution instruction received in S1 of Figure 3 is an example of the first instruction in this specification. Also, the response data received in S34 of Figure 6 is an example of the second instruction. In addition, although the above explanation includes user authentication information in the second instruction which is different from the first instruction, it is not limited to this. User authentication information may also be included in the first instruction. That is, user authentication information may be included in the pull scan execution instruction that is first transmitted and received by the MFP10 in S1. Then, the controller 11 may make the decisions in S35 and S36 based on the user authentication information included in the first instruction received in S1. In this case, it is not necessary to request the external device side password PWB in S34, but communication related to the transmission and reception of scan data will occur between the MFP10 and the PC40 even after the first instruction has been exchanged. The instructions in this communication are an example of the second instruction. Furthermore, in the first pull-scan method described above, the controller 11 may also include user authentication information in the first pull-scan execution instruction that the MFP 10 receives in S1.

[0059] As shown in Figure 8, when the controller 11 starts processing S36, it determines whether the first pull scan method is set (S60). In this example, the second pull scan method is set (S60: NO), so the controller 11 executes S66. The controller 11 determines whether the user who requested the pull scan matches the logged-in user, similar to S72 in Figure 9 which has already been explained (S66). The controller 11 determines whether the user authentication information received from the PC 40 in processing S34, for example, the user ID and password, matches the user ID and password of the logged-in user (in this example, the user ID and password of user A) (S66).

[0060] In S66 and S72, the condition for determining that the user authentication information included in the pull scan execution instruction matches the user authentication information of the logged-in user is that the user ID and password match exactly. However, in this specification, "corresponding user authentication information" does not necessarily mean that the user ID and password match exactly. For example, it may be determined that the user authentication information matches if part of the username matches. The controller 11 may also request only one of the user ID or password as user authentication information and determine whether the other information matches. Therefore, in this specification, user authentication information may be either a user ID or a password.

[0061] Furthermore, even if the user IDs do not match, if the information indicates essentially the same user, it may be considered that the users are the same. For example, if one of the two pieces of user authentication information is a user ID and the other is a username that corresponds to that user ID, it may be considered that the user authentication information is the same. Also, if the user authentication information includes information indicating the group to which the user belongs, it may be considered that the user authentication information is the same if they belong to the same group. In addition, the user authentication information may be information that can identify a user other than a user ID or password, such as the PC name and IP address of PC40.

[0062] If controller 11 determines that the user matches (S67:YES), it executes S63 and sets the authentication completion flag to a value indicating success (true). However, if controller 11 determines that the user authentication information does not match (S67:NO), it sets the authentication completion flag to a value indicating user authentication failed (false) (S64). If the value indicating user authentication failed (false) is set, controller 11 determines in S37 of Figure 6 that user authentication has failed (S37:NO) and executes S41.

[0063] In this example, controller 11 determines in S37 of Figure 6 that user authentication has been successful (S37: YES) and executes the scan permission confirmation process in S38. As shown in Figure 9, when controller 11 starts the process in S38, it determines whether the first pull scan method is set or not (S70). In this example, the second pull scan method is set (S70: NO), so controller 11 executes S75.

[0064] The processing from S75 onwards is the same as when the first pull scan method is set and the user is logged out. In this example, the function "Scan" corresponding to "User A" has a restriction setting value "Restriction" (see Figure 2), so the controller 11 determines that there is a restriction on the function "Scan" (S76: YES) and sets the scan permission flag to a value indicating that scanning is not permitted (S74). In S39 of Figure 6, the controller 11 executes S41 because scanning is not permitted (S39: NO). That is, when the second pull scan method is set and the user is logged in, the pull scan is restricted for "User A" who has a restriction on push scanning set, even if authentication by the user authentication process in S36 is successful.

[0065] Next, we will explain the process when "User B" is logged into MFP10 and "User B" issues a command to perform a pull scan. In this example, controller 11 executes the processes S31 to S37 in Figure 6, which have already been explained. As shown in Figure 9, in this example, the second pull scan method is set (S70: NO), so controller 11 executes S75. In S75, controller 11 permits the start of a pull scan (S77) because the restriction setting value corresponding to the "Scan" function of "User B" is "Allowed" (S76: NO). That is, when the second pull scan method is set and "User B" is logged in, a pull scan is performed for "User B" who is allowed to perform push scans, provided that authentication is successful.

[0066] Next, we will explain the processing when the function "SFL" is set to disabled "OFF" in the SFL database 19. In this example, the controller 11 makes a positive judgment in S31 of Figure 6, which has already been explained (S31: YES), executes S32, and in S50 of Figure 7, since the function "SFL" is disabled "OFF" (S50: NO), executes S55. In other words, regardless of whether the first pull scan method or the second pull scan method is set, if the function "SFL" is disabled, pull scans are not restricted for anyone.

[0067] The embodiment described above can achieve the following effects. When the controller 11 of the MFP10 receives a pull scan execution command from the PC40, if the MFP10 is logged in (S57:YES), and if the user authentication information included in the pull scan execution command corresponds to the user authentication information of the logged-in user (S67:YES), the controller 11 executes the pull scan (S63). If the two sets of user authentication information do not correspond (S67:NO), the controller 11 restricts the pull scan (S64). Also, when the controller 11 receives a pull scan execution command from the PC40, if the MFP10 is not logged in (S57:NO), the controller 11 does not require the two sets of user authentication information to correspond (S55) and executes the pull scan.

[0068] According to this, when controller 11 receives a pull scan execution command, if it is logged in, it determines the correspondence between the user authentication information included in the execution command and the user authentication information of the logged-in user. If the two user authentication information pieces match, controller 11 executes the pull scan; otherwise, it restricts the pull scan. This allows a user executing a pull scan from PC 40 to require user authentication to execute the pull scan by logging into MFP 10. This also restricts other users from executing pull scans.

[0069] Furthermore, if the controller 11 is logged out when it receives a pull scan execution command, it will execute the pull scan without determining whether the user authentication information is correct. This means that if the user executing the pull scan from PC 40 determines that authentication is not required, they can log out MFP 10 and send a pull scan execution command, thereby executing the pull scan without performing authentication using user authentication information. Therefore, even users who are not administrators of MFP 10 but can log in can switch whether authentication is required or not for executing a pull scan. This improves usability in the authentication process associated with executing a pull scan.

[0070] Furthermore, when the controller 11 receives a pull scan execution command from the PC 40, if the MFP 10 is logged in and the two user authentication credentials correspond (S67: YES), the controller 11 will execute the pull scan (S77) if the restriction setting value does not indicate that the pull scan of the logged-in user should be restricted (S76: NO), and will restrict the pull scan (S74) if the restriction setting value indicates that the pull scan of the logged-in user should be restricted (S76: YES).

[0071] According to this, the controller 11 can set restriction values ​​for pull scans on a per-user basis using the "SFL" function. The controller 11 checks whether the logged-in user has permission to perform a pull scan when two user authentication credentials match. Only if the user is permitted to perform a pull scan can the controller 11 allow the pull scan to be performed. It is possible to restrict logged-in users who are restricted from performing pull scans from performing a pull scan upon successful user authentication.

[0072] Furthermore, in the above embodiment, the pull scan execution instruction from PC40 consists of multiple instructions (S1, S34), and the first instruction that is sent first (S1) does not contain user authentication information. When the controller 11 receives the pull scan execution instruction from PC40, if the MFP10 is logged in (S57: YES), it requests PC40 to provide a second instruction from the multiple instructions that constitute the pull scan execution instruction, which can include user authentication information (S34). The controller 11 determines the correspondence between the user authentication information included in the second instruction received from PC40 and the user authentication information of the logged-in user (S67).

[0073] According to this, after confirming that the user is logged in, user authentication information can be requested from PC40. If the user is logged out, unnecessary user authentication information can be prevented from being sent to PC40. Furthermore, user authentication information can only be sent from PC40 if the user is logged in.

[0074] Furthermore, the first instruction that is initially sent may include user authentication information. When the controller 11 receives a pull scan execution instruction from the PC 40, if the MFP 10 is logged in, it may determine the correspondence between the user authentication information included in the first instruction and the user authentication information of the logged-in user.

[0075] This reduces the number of communications between the MFP10 and PC40. Furthermore, because user authentication information is obtained at the first instruction stage, user authentication can be initiated more quickly if the user is logged in.

[0076] Furthermore, the controller 11 can switch between a first pull scan method and a second pull scan method as methods for executing pull scans. When the first scan method is set, the controller 11 decides whether or not to perform user authentication depending on whether or not the restriction setting value of the "Scan" function of the "SFL" function is "restricted" (S53). When the second scan method is set, the controller 11 decides whether or not to perform user authentication depending on whether or not the user is logged in (S57).

[0077] According to this, by selecting the first or second pull scan method, the conditions for determining whether or not user authentication is required during a pull scan can be changed. With the first pull scan method, for example, only administrators who can operate the restriction setting screen 30 in Figure 2 can change the restriction setting value of the "Scan" function of the "SFL" function, and thus change whether or not user authentication is required when performing a pull scan. With the second pull scan method, any user who can log in to the MFP10 can change whether or not user authentication is required when performing a pull scan depending on whether or not they log in before the pull scan is performed.

[0078] (Other embodiments) The reading device is not limited to the above embodiment, and various modifications are possible without departing from its spirit. The order and content of the processes shown in Figures 3 to 9 in the above embodiment are just examples. For example, in the above embodiment, the controller 11 was capable of executing both the first and second pull-scan methods, but it may also be configured to be capable of executing only the second pull-scan method. Furthermore, in the second pull scan method, if authentication using user authentication information is successful, the controller 11 may allow the execution of the pull scan regardless of the restriction settings for the logged-in user. For example, if the controller 11 makes a negative judgment in S70 (S70: NO), it may execute S77 without executing S75 and S76. Furthermore, the controller 11 may be configured to allow setting a time limit for maintaining the logged-in state. For example, the controller 11 may log out if, after logging in, there is no user input to the user IF16 for a period equal to the timeout period. In this case, the controller 11 may reset the time measured for the period of no user input to the user IF16 each time it receives a pull scan execution instruction.

[0079] In the above embodiment, the controller 11 performed authentication of usernames and passwords and functional restrictions using the SFL database 19, but authentication and functional restrictions may be performed using other information. For example, "Active Directory Authentication" or "LDAP Authentication" may be used. For example, if the controller 11 uses "Active Directory Authentication", it may perform login authentication to the MFP 10 based on authentication information stored in the Active Directory® server. The controller 11 may also perform restrictions on scanning functions, etc., using user-specific restriction settings stored in the Active Directory server. The controller 11 also uses "LDAP Authentication", and may perform login authentication to the MFP 10 based on authentication information stored in the LDAP (Lightweight Directory Access Protocol) server. The controller 11 may also perform functional restrictions using restriction settings stored in the LDAP server. Furthermore, the above authentication and restriction methods may be used in combination or switched between. Also, the authentication information and restriction settings may be stored in different storage units. For example, the controller 11 may perform login authentication to the MFP 10 based on authentication information stored on the server and store the restriction settings in the SFL database 19 in memory 12.

[0080] In the above embodiment, the limit setting value for the "SFL" function was set using a web page sent from the controller 11 of the MFP10. Alternatively, the limit setting value for the "SFL" function may be set by operating the user IF16 of the MFP10. Therefore, the controller 11 may accept changes to the limit value, etc., in response to operations on the user IF16, similar to the web page. The restriction settings for the "Scan" function in SFL database 19 were applied to both push scans and pull scans. However, it would also be possible to set up separate checkboxes for push scans and pull scans to accept the presence or absence of restrictions separately. As an example of a reading device, the MFP10 was used in the explanation, but the reading device may be any device capable of performing only the "scanner" function. [Explanation of symbols]

[0081] 10 MFC (Reader), 11 Controller, 15 Scanner, 16 User Interface (User IF), 40 PC (External Device).

Claims

1. User interface and Scanner and Controller and A reading device equipped with, The aforementioned controller, It is possible to perform push scans, in which the scanner reads a document based on execution instructions corresponding to operations on the user interface, and pull scans, in which the scanner reads a document based on execution instructions from an external device. The aforementioned controller, When the reader receives an instruction to execute the pull scan from the external device, and the reader is logged in, if the user authentication information included in the instruction to execute the pull scan corresponds to the user authentication information of the logged-in user, the reader executes the pull scan; if the user authentication information included in the instruction to execute the pull scan does not correspond to the user authentication information of the logged-in user, the reader restricts the pull scan. The aforementioned controller, When the reader receives an instruction to execute the pull scan from the external device, if the reader is not logged in, the reader will execute the pull scan without requiring a correspondence between the user authentication information included in the pull scan instruction and the user authentication information of a logged-in user. A reading device configured in such a way.

2. The aforementioned controller, It is possible to set a limit value for the pull scan limit, The aforementioned controller, When the reader receives an instruction to execute the pull scan from the external device, and the reader is logged in and the user authentication information included in the instruction to execute the pull scan corresponds to the user authentication information of the logged-in user, the reader will perform the pull scan if the restriction setting value is not indicated, and will restrict the pull scan of the logged-in user if the restriction setting value is indicated. The reading device according to claim 1, configured as described above.

3. The instruction to execute the pull scan from the external device is: It consists of multiple instructions, and of these instructions, the first instruction that is sent first does not contain the user authentication information. The aforementioned controller, When the reader receives an instruction to execute the pull scan from the external device, if the reader is logged in, it requests the external device to provide a second instruction from among the multiple instructions that constitute the pull scan instruction, which can include the user authentication information, and determines the correspondence between the user authentication information included in the second instruction received from the external device and the user authentication information of the logged-in user. The reading device according to claim 1 or claim 2, configured as described above.

4. The instruction to execute the pull scan from the external device is: It consists of multiple instructions, and the first instruction that is sent first contains the user authentication information. The aforementioned controller, When the external device receives an instruction to perform the pull scan, if the reader is logged in, it determines the correspondence between the user authentication information included in the first instruction and the user authentication information of the logged-in user. The reading device according to claim 1 or claim 2, configured as described above.

5. The aforementioned controller, It is possible to set limit values ​​for the aforementioned push scan restrictions. The aforementioned controller, When an instruction to execute the push scan is received via the user interface, it is possible to restrict the push scan according to the limit setting value related to the restrictions on the push scan. The aforementioned controller, It is possible to switch between the first method and the second method as the method for executing the pull scan. The aforementioned controller, When the first method is set and the external device receives an instruction to execute the pull scan, if the limit setting value for the push scan restriction indicates that the push scan should be restricted, then if the user authentication information included in the instruction to execute the pull scan corresponds to the user authentication information of the logged-in user, the pull scan is executed; if the user authentication information included in the instruction to execute the pull scan does not correspond to the user authentication information of the logged-in user, the pull scan is restricted. The aforementioned controller, When the first method is set and the external device receives an instruction to execute the pull scan, if the limit setting value for the push scan restriction does not indicate that the push scan should be restricted, the pull scan will be executed without requiring a correspondence between the user authentication information included in the instruction to execute the pull scan and the user authentication information of the logged-in user. It is configured in such a way, The aforementioned controller, When the second method described above is set and the external device receives an instruction to execute the pull scan, if the reader is logged in, the pull scan is executed if the user authentication information included in the instruction to execute the pull scan corresponds to the user authentication information of the logged-in user; otherwise, the pull scan is restricted. The aforementioned controller, When the second method described above is set and the external device receives an instruction to execute the pull scan, if the reader is not logged in, the pull scan is executed without requiring a correspondence between the user authentication information included in the pull scan execution instruction and the user authentication information of a logged-in user. The reading device according to claim 1 or claim 2, configured as described above.

Images