Image forming apparatus and control method, server and control method, and storage medium

Abstract

The invention provides an image forming apparatus, a control method, a server, a control method, and a storage medium. An image forming apparatus configured to communicate with a terminal having an authentication function transmits verification data for performing user authentication of the image forming apparatus to the terminal, receives signature data from the terminal, and transmits the signature data to the terminal. The signature data is obtained by encrypting the verification data using a secret key corresponding to authentication based on execution of the authentication in an authentication function of the terminal, and performing verification of the received signature data using the verification data and a public key corresponding to the secret key, when the authentication is successful, a function on the premise of the user authentication is provided.

Description

Technical Field

[0001] The present invention relates to a technique for authenticating a user who uses a device. Background Art

[0002] In recent years, as a method for authenticating users, technologies such as FIDO2.0 defined by the Fast Identity Online (FIDO) Alliance are known. It is a technology that performs biometric authentication on a terminal that the user has at hand and verifies data signed using a secret key on the terminal on the authentication server side.

[0003] On the other hand, as in Japanese Patent Laid-Open No. 2023-37169, as a technology of an image forming apparatus, a technology of performing authentication using an integrated circuit (IC) card or performing authentication based on a password input by a user is known.

[0004] However, in the technology discussed in Japanese Patent Laid-Open No. 2023-37169, like FIDO, it has become impossible to provide the function of the image forming apparatus based on the verification of data signed in the terminal. Summary of the invention

[0005] According to one aspect of the present invention, an image forming device is configured to communicate with a terminal having an authentication function, the image forming device comprising: at least one memory storing at least one program; and at least one processor, wherein the at least one processor reads the at least one program from the at least one memory and executes the at least one program so that the image forming device: transmits verification data for performing user authentication of the image forming device to the terminal, receives signature data from the terminal, the signature data being obtained by encrypting the verification data using a secret key corresponding to the authentication based on execution of authentication in an authentication function of the terminal, and verifies the received signature data using the verification data and a public key corresponding to the secret key, wherein, if the verification is successful, provides a function premised on the user authentication.

[0006] Further features of the present invention will become apparent from the following description of exemplary embodiments with reference to the attached drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] Figure 1 is a diagram showing a system configuration.

[0008] Figure 2A and Figure 2B is a diagram showing a hardware configuration.

[0009] Figure 3 is a diagram showing a software configuration.

[0010] Figure 4 is a diagram showing information stored in a user database.

[0011] Figure 5 is a diagram showing a user interface to be displayed on an operation panel of a multifunction peripheral (MFP).

[0012] Figure 6 is a diagram showing a user interface for settings related to user authentication.

[0013] Fig. 7A and Figure 7B It is a diagram showing a sequence of passkey registration.

[0014] Fig. 8A and Figure 8B is a diagram showing a pass key authentication sequence.

[0015] Fig. 9 is a diagram illustrating a software configuration of a mobile terminal according to other exemplary embodiments.

[0016] Fig.10 2 is a diagram showing a user interface of a mobile terminal during pass key registration.

[0017] Fig.11 It is a diagram showing a user interface of a mobile terminal during passkey authentication.

[0018] Fig.12 is a diagram illustrating a user interface of a mobile terminal according to other exemplary embodiments.

[0019] Fig.13 FIG. 1 is a diagram showing a user interface to be displayed on the operation panel of the MFP.

[0020] Fig.14 is a diagram showing a user interface for settings related to simple login.

[0021] Fig.15A and Fig. 15B This is a flowchart showing the processing to be executed when simple login is enabled.

[0022] Fig.16 is a diagram showing a system configuration according to a third exemplary embodiment.

[0023] Fig.17 is a diagram showing the hardware configuration of the MFP login server.

[0024] Fig.18 is a diagram showing a software configuration according to the third exemplary embodiment.

[0025] Fig.19 It is a diagram showing account information.

[0026] Fig. 20 It is a diagram showing MFP management information.

[0027] Fig.21 is a diagram showing a user interface related to settings.

[0028] Fig. 22 It is a diagram showing a user interface related to login.

[0029] Fig.23 It is a diagram showing communication between the MFP and the MFP registration server.

[0030] Fig.24 It is a diagram showing the flow of processing to be executed by a central processing unit (CPU).

[0031] Fig.25 2 is a diagram showing an example of an operation screen and an operation flow of a mobile terminal.

[0032] Fig.26A and Fig.26B It is a diagram showing the flow of processing related to pass key registration.

[0033] Fig.27A and Fig.27B It is a diagram showing the flow of processing related to pass key authentication.

[0034] Fig.28 is a diagram showing an operation screen of a mobile terminal to be displayed in a case where an MFP application is to be used.

[0035] Fig.29 is a diagram showing a user interface to be displayed on an operation panel of an MFP according to a fifth exemplary embodiment.

[0036] Fig. 30A and Fig. 30B : is a diagram showing the flow of processing for pass key registration and pass key authentication according to the fifth exemplary embodiment. DETAILED DESCRIPTION

[0037] Hereinafter, exemplary embodiments of the present invention will be described with reference to the accompanying drawings.

[0038] An exemplary embodiment of the present invention will be described using an example of a multifunction peripheral (MFP) having functions such as copying, printing, and scanning as an example of an image forming apparatus to which the present invention is applicable.

[0039] In the present exemplary embodiment, as an authentication system that allows a user to use functions or services provided by an image forming apparatus, a digital signature verification technique also used in Fast Identity Online (FIDO) is adopted. Specifically, the technique described in the present exemplary embodiment relates to a system for authenticating a user by performing biometric authentication on a mobile terminal (information processing apparatus) held by the user and verifying digital signature data output as a result of the biometric authentication on the image forming apparatus side. As one of the features of the present exemplary embodiment, a digital function corresponding to the FIDO service to be provided by the FIDO technique is installed on the image forming apparatus, as described below. Although FIDO is mentioned as an example of such a system, it should be noted initially that the present invention is not limited to the standards defined by the FIDO Alliance. In addition, the authentication to be performed on the mobile terminal is not limited to biometric authentication. As described below, the authentication to be performed on the mobile terminal may be, for example, authentication using a passcode.

[0040] <System Configuration>

[0041] Reference will be made to Figure 1 describe the system configuration according to the first exemplary embodiment. The MFP 101 is an MFP to which the present invention is applicable. The mobile terminal 102 is a mobile terminal such as a smart phone. The mobile terminal is a terminal equipped with the iPhone operating system (iOS) of Apple Inc. or a terminal equipped with (Android) of Google LLC. The mobile terminal 102 can communicate with the MFP 101 via an access point 103 of a wireless local area network (LAN) or a wired LAN 104.

[0042] When the MFP 101 has a wireless LAN access point function, the mobile terminal 102 can directly communicate with the MFP 101 by connecting to the wireless LAN access point function of the MFP 101.

[0043] <Hardware Configuration of MFP 101>

[0044] Figure 2A is a schematic diagram showing the hardware configuration of the MFP 101. The CPU 201 is a central processing unit (processor) that controls the operation of the entire MFP 101. The random access memory (RAM) 203 is a volatile memory that serves as a work area and is used as a temporary storage area for loading various control programs stored in the read only memory (ROM) 202 and the hard disk drive (HDD) 204.

[0045] The ROM 202 is a volatile memory and stores a boot program of the MFP 101. The HDD 204 is a nonvolatile hard disk or a flash memory device having a larger capacity than the RAM 203. The HDD 204 stores an MFP control program. The HDD 204 also stores an operating system (OS) and application programs.

[0046] When the MFP 101 is activated, the CPU 201 executes a boot program stored in the ROM 202. The boot program is a program for reading out a program of an operating system (OS) stored in the HDD 204 and loading the program onto the RAM 203. If the CPU 201 executes the boot program, the CPU 201 then executes the program of the OS loaded on the RAM 203 and performs control of the MFP 101. The CPU 201 also stores data to be used for operations based on the control program on the RAM 203 to read and write.

[0047] In the MFP 101, one CPU 201 executes each process shown in the sequence diagram to be described below, but other configurations may be adopted. For example, a configuration in which a plurality of CPUs and microprocessors (MPUs) cooperate to execute each process shown in the sequence diagram to be described below may be adopted. A part of the process to be described below may be executed using a hardware circuit such as an application specific integrated circuit (ASIC) or a field programmable gate array (FPGA).

[0048] The operation panel 205 is a touch-operable display (touch panel). The printer 206 is a printer engine for printing print data received from the outside via the communication unit 208 and digital data acquired from the scanner 207. The scanner 207 is a scanner device for reading a paper document and converting an image read from the paper document into digital data. The communication unit 208 is a network interface for connecting to the Internet or a local area network (LAN) of an office.

[0049] <Hardware Configuration of Mobile Terminal 102>

[0050] Figure 2B 2 is a schematic diagram showing the hardware configuration of the mobile terminal 102. The CPU 211 is a central processing unit (processor) that controls the operation of the entire mobile terminal 102. The RAM 213 is a volatile memory used as a work area and as a temporary storage area for loading various control programs stored in the ROM 212 and the flash memory device 214.

[0051] ROM 212 is a volatile memory and stores a boot program of mobile terminal 102. Flash memory device 214 is a nonvolatile memory device having a larger capacity than RAM 213. Flash memory device 214 stores a mobile terminal control program. Flash memory device 214 also stores an OS and application programs.

[0052] The operation panel 215 is a display (touch panel) that can be operated by touch.

[0053] The camera 216 can be used to take photos and moving images and read quick response (QR) (Quick Response The front camera 217 is a camera that can be used to take an image of a user of the mobile terminal and perform facial authentication for the user. The fingerprint sensor 218 is a sensor that can be used for fingerprint authentication. The communication unit 219 is a network interface for wireless communication.

[0054] <Software Configuration>

[0055] Figure 3 1 is a schematic diagram showing the software configuration of the MFP 101 and the mobile terminal 102. The MFP 101 includes an operation unit login service 301 for authenticating a user using the MFP 101. The operation unit login service 301 includes a login processing unit 302 and a FIDO service 303. The login processing unit 302 displays a login screen on the operation panel 205, authenticates the user using the operation panel 205, and allows the user to log in to the operation panel 205. The FIDO service 303 has a web server function that enables communication that complies with the Hypertext Transfer Protocol (HTTP). The FIDO service 303 also has an authentication function of Web Authentication (WebAuthn) defined by the FIDO Alliance or the World Wide Web Consortium (W3C).

[0056] The operation unit user interface (UI) service 304 of the MFP 101 provides a user interface for providing functions to a user who has logged in to the operation panel 205. The operation unit UI service 304 includes a menu for the user to select a function, an application, and a user interface (UI) platform for managing screen transitions. For example, the operation unit UI service 304 includes a "copy" application that provides a UI for a copy function to the user, a "print" application that provides a UI for a print function, and a "scan and send" application that provides a UI for transmitting a scanned document to the outside.

[0057] The printer control unit 305 is a software module for controlling the printer 206, and the scanner control unit 306 is a software module for controlling the scanner 207. Each software module provides an application programming interface (API) for operating the printer 206 or the scanner 207 to a corresponding application. The software configuration of the MFP 101 includes an operating system (not shown) and driver software (not shown) for controlling various types of hardware.

[0058] The mobile terminal 102 includes an operating system (OS) 311. Depending on the terminal, the OS 311 includes iPhoneOS (iOS) of Apple Inc. or iOS of Google LLC. Authenticator 312 is software having a FIDO authenticator function defined by the FIDO Alliance. The function of authenticator 312 can be incorporated into the operating system (OS 311) as a function of the operating system. Camera application 313 is an application for controlling camera 216 and front camera 217 to take photos and moving images. Camera application 313 also has a function of reading and decoding QR codes. Web browser 314 is software that operates as a client function for HTTP communication. Web browser 314 includes Safari of Apple Inc., Chrome of Google LLC, or Edge of Microsoft Corporation.

[0059] <User Account>

[0060] Figure 4 4 is a schematic diagram showing a user database to be stored in the HDD 204 of the MFP 101. The MFP 101 stores user account information in the user database 401 stored in the HDD 204 and manages the user account information. After encryption or tampering prevention of the communication path or storage device is performed, the database of other nodes on the network can be used. In the user database 401, the user identification (ID), password, pass key information (credential ID, public key) to be used for FIDO authentication, role, email address, and validation status / invalidation status of password authentication are recorded.

[0061] "User ID" is an identifier for identifying a user. "Password" is a password to be used in authentication. "Role" is information indicating the user's authority to use MFP 101. Examples of each role and the authority to use are shown in role information table 402. In addition to the definition of roles that have been set in MFP 101 at factory shipment, it is also possible to enable the user to create a new role by setting detailed authority to use.

[0062] The following will refer to Figure 6The UI of the user account management screen 602 or the user account editing screen 603 is described to perform registration, editing, and deletion of user account information.

[0063] The user is authenticated by referring to the user database from the operation unit login service 301. The pass key information (credential ID, public key) is stored via the FIDO service 303.

[0064] <User authentication function>

[0065] Next, we will refer to Figure 5 and Figure 6 Describe the user authentication function that MFP 101 has. In the present exemplary embodiment, two types of user authentication will be described. The first type is authentication using a password input by the user on the operation panel 205. The second type is authentication in which the operation unit login service 301 authenticates the user by using the technology of the public key infrastructure (PKI) defined by FIDO. That is, authenticating the user based on the result obtained by using a public key to verify the signature data obtained by encrypting a challenge using a secret key will be referred to as user authentication. In the present exemplary embodiment, in addition to user authentication, authentication for authenticating the owner of the mobile terminal is performed in the mobile terminal. This authentication is authentication in step S715 or step S814 to be described below. In this way, in the present exemplary embodiment, there are multiple types of authentication.

[0066] Figure 5 It is a schematic diagram showing a login screen to be displayed on the operation panel 205 and a menu screen to be displayed after login. Figure 6 is a diagram showing a setting screen for setting a login method and performing user account management. Figure 5 When the setting menu is selected in the management setting screen 504 shown in FIG. Figure 6 The various screens shown.

[0067] On the screen of the login method setting 601 of the operation unit UI, the user can select a method to be used when the user logs in to the operation panel 205 by performing user authentication. In the present exemplary embodiment, a user operation to select an authentication method from options including "password authentication" using a password input by the user and "mobile authentication (pass key authentication)" using a pass key including a public key can be received, and the selected authentication method can be validated. In the case where these two methods are validated on the screen of the login method setting 601, the login processing unit 302 can receive the selection of the authentication method on the mobile authentication screen 501 and the password authentication screen 502. In the present exemplary embodiment, a password authentication button 508 is displayed on the mobile authentication screen 501 to receive the selection of password authentication. In addition, a mobile authentication button 509 is displayed on the password authentication screen 502 to receive the selection of mobile authentication.

[0068] Password authentication provides a login method that prompts the user to enter a user ID and password. Specifically, the login processing unit 302 displays a password authentication screen 502 as a login screen on the operation panel 205. The user can use a hardware key or a software key (not shown) set on the MFP 101 to enter the user ID and password. The login processing unit 302 receives the input of the user ID and password via the hardware key or the software key. Then, the login processing unit 302 verifies whether there is user account information identical to the combination of the received user ID and password in the user database 401. Then, in the case where the user account information exists, it is determined that the user authentication has been successful and the post-login menu screen is displayed.

[0069] Mobile authentication (passkey authentication) is performed in cooperation between the login processing unit 302, the FIDO service 303, and the authenticator 312 of the mobile terminal 102. Mobile authentication authenticates the user by using a technology that uses a public key infrastructure (PKI) defined by FIDO called a passkey.

[0070] When mobile authentication (pass key authentication) is enabled, a mobile authentication screen 501 is displayed as a login screen for user authentication on the operation panel 205. Registration of a pass key and an authentication method using the pass key will be described in detail below.

[0071] When both password authentication and mobile authentication (passkey authentication) are set to a valid state, by displaying the password authentication button 508 and mobile authentication button 509 displayed on the login screen, the user can use these two types of authentication by switching the display of the login screen.

[0072] In a case where authentication of the user succeeds through password authentication or mobile authentication (passkey authentication), the login processing unit 302 allows the user to log in to the operation panel 205 .

[0073] If the login has succeeded, the operation unit UI service 304 that has detected the login of the user displays the menu screen 503 on the operation panel 205. Then, the operation unit UI service 304 provides a function premised on user authentication.

[0074] Examples of functions that require user authentication include a print function to be executed with a predetermined print setting by the printer 206. When a user assigned a role of an administrator or general user is authenticated, printing with a color print setting becomes executable. When a user assigned a role of a limited user is authenticated, only printing with a monochrome print setting is permitted.

[0075] Examples of functions premised on user authentication also include a function of transmitting, to an external device, image data obtained by scanning performed by the scanner 207. This function is provided to a user assigned a role of an administrator or a general user when the user is authenticated.

[0076] Examples of functions that presuppose user authentication also include a function of using an address book when specifying a transmission destination of image data obtained by scanning performed by the scanner 207. The address book is a list in which information related to one or more transmission destinations is registered. A user assigned the role of a general user can specify a transmission destination of image data by selecting a transmission destination from the address book. A user assigned the role of an administrator can register a new transmission destination on the address book and edit the address book in addition to being able to select a transmission destination from the address book.

[0077] Examples of functions that presuppose user authentication also include functions for making settings for the MFP 101. When displayed on the management setting screen 504, the settings for the MFP 101 include operation unit UI login method settings, settings related to each user account, device settings, and network settings. In the case where a user assigned the role of administrator is authenticated, these setting functions are provided to enable the user to make settings for the MFP 101. The device settings include settings related to a print job or a scan job, such as settings indicating whether to display a history to be recorded when a job is executed on the operation panel 205. The network settings include, for example, settings indicating whether to permit the use of each printing protocol in printing.

[0078] <Simple login function>

[0079] Reference Fig.13 and Fig.14 A simple login function that the MFP 101 has is described. Fig.13 It is a schematic diagram showing a login screen to be displayed on the operation panel 205 and a menu screen to be displayed after login. Fig.14 This is a diagram showing how to enable the simple login function and how to Figure 4 The role shown is a diagram of the settings for enforcing the authentication method to be used after a simple login. For example, in Fig.14 In the illustrated setting 1403, if the user's role is an administrator or a general user, a screen for FIDO authentication is displayed after simple login, and the user is prevented from logging into the MFP 101 before authentication is performed through FIDO authentication. This forces FIDO authentication to be performed after simple login. If the user's role is a limited user, a screen for FIDO authentication is not displayed after simple login, and the user directly logs into the MFP 101. That is, authentication after simple login is not mandatory. When the user logs in from Figure 5 When the setting menu is selected in the management setting screen 504 shown in FIG. Fig.14 The screen shown.

[0080] If the login processing unit 302 detects that the validation button 1402 shown in the simple login setting screen 1401 has been pressed, the login processing unit 302 validates the simple login function. When the simple login function is validated, the login processing unit 302 displays a Figure 4 A button or icon of a user registered in the user database shown. Via the button or icon, the login processing unit 302 receives a selection of a button corresponding to the user's user ID from the user. By causing the user to select a button corresponding to the user's avatar, the login processing unit 302 allows the user to log in to the MFP 101. That is, the login processing unit 302 performs a login process using the user ID and password of the user corresponding to the button selected from the buttons displayed on the login screen. This enables the user to skip the input of the user ID and password. In order to prevent unauthorized login, simple login can be used in combination with the FIDO service function to be described below. Due to the setting 1403 for enforcing the authentication method for each role, an authentication method to be enforced in combination with simple login can be set for each user using the device.

[0081] Fig.13An example of a simple login screen 1301 is shown. In the case where it is detected that the user has selected a button on the simple login screen 1301, the login processing unit 302 advances the process to the login process to allow the user to log in to the operation panel 205. As another possible configuration, a password or a pattern may be set for each user, and the user may be allowed to log in to the operation panel 205 by inputting a correct password or pattern. In this case, in the case where the authentication using the password or pattern has succeeded, the login processing unit 302 advances the process to the login process.

[0082] Here, in the case where the button of the user who has performed the passkey registration as shown in the user database 401 is selected, the mobile authentication screen 1302 is displayed. After the FIDO authentication process is performed on the mobile authentication screen 1302, the login processing unit 302 allows the user to log in to the operation panel 205.

[0083] In the case where the user performs their first login and the user's pass key is not registered in the user database 401, a registration screen 1306 is displayed for prompting the user to perform pass key registration. In the case of performing pass key registration, the login processing unit 302 displays a pass key registration screen 1307 and allows the user to log in to the operation panel 205 after the registration process ends.

[0084] In the case where it is determined that there is no need to perform pass key registration based on the setting 1403 and the information indicating whether the login is the first login, the login processing unit 302 allows the user to log in to the operation panel 205 .

[0085] Next, the operation to be performed when the setting 1403 for forcing the authentication method for each role is enabled will be described. When the setting 1403 for forcing the authentication method for each role is enabled and the user has performed the passkey registration, the mobile authentication screen 1302 is displayed. After the FIDO authentication process is performed on the mobile authentication screen 1302, the login processing unit 302 allows the user to log in to the operation panel 205.

[0086] In the case where the setting 1403 for forcing the authentication method for each role is enabled and the user has not performed the pass key registration, the pass key registration screen 1305 is displayed. In the case where the pass key registration is performed, the login processing unit 302 displays the pass key registration screen 1307, and allows the user to log in to the operation panel 205 after the registration process ends. In the case where the pass key registration is not performed, the login processing unit 302 displays the simple login screen 1301 again. If the login has succeeded, the operation unit UI service 304 that has detected the login of the user displays the menu screen 1303 on the operation panel 205.

[0087] <FIDO Service Function>

[0088] The FIDO service 303 has a web server function that enables HTTP-compliant communication. The FIDO service 303 also has an authentication function for WebAuthn defined by the FIDO Alliance or the W3C.

[0089] The web browser 314 of the mobile terminal 102 that has read the QR code displayed on the mobile authentication screen 501 or the passkey registration screen 506 accesses the FIDO service 303 via HTTPS communication. The FIDO service 303 provides access and functions to, for example, the following URLs 1 to URL 6 as a web server.

[0090] <url1>

[0091] https: / / mfp101.office.local / LocalUI / registration / random numbers

[0092] URL1 is a Uniform Resource Locator (URL) that returns the HTML for passkey registration. The random numbers in URL1 correspond to strings such as "52f3d66abc7519a209af9de1d96136c9". These random numbers are the same as the strings to be embedded in the QR code on the passkey registration screen 506.

[0093] The HTML for passkey registration returned by URL1 covers JavaScript for accessing the Representational State Transfer (REST) APIs of the following URL2 and URL3. The HTML also covers the JavaScript of the following WebAuthn defined by FIDO2.0.

[0094] <JavaScript of WebAuthn>

[0095] Output JavaScript Object Notation (JSON) data = await navigator.credentials.create(input JSON data);

[0096] <url2>

[0097] https: / / mfp101.office.local / LocalUI / registration / challengeURL2 is the URL of the REST API that returns the input JSON data to be input to the above-mentioned API "navigator.credentials.create()". The input JSON data includes the challenge data issued by the FIDO service 303. The challenge corresponds to a random number and is verification data to be used in verification for passkey registration.

[0098] <url3>

[0099] https: / / mfp101.office.local / LocalUI / registration / verification

[0100] URL3 is the URL of the REST API for receiving information for passkey registration. Receive the output JSON data output by the above API "navigator.credentials.create()". The output JSON data includes the credential ID, challenge, public key and digital signature issued by the mobile terminal 102.

[0101] <url4>

[0102] https: / / mfp101.office.local / LocalUI / authentication / random numbers

[0103] URL4 is the URL that returns the HTML for passkey authentication. The random number corresponds to a string such as "b15dee080a1a549be6e3c74e6b59f5c5". The random number is the same as the string to be embedded in the QR code on the mobile authentication screen 501.

[0104] The HTML for passkey authentication returned by URL4 covers the JavaScript for the REST APIs for accessing the following URLs 5 and 6. The HTML also covers the JavaScript for the following WebAuthn defined by FIDO2.0.

[0105] <JavaScript for WebAuthn>

[0106] Output JSON data = await navigator.credentials.get(Input JSON data);

[0107] <url5>

[0108] https: / / mfp101.office.local / LocalUI / authentication / challenge

[0109] URL5 is a URL of a REST API that returns the above-mentioned input JSON data to be input to the above-mentioned "navigator.credentials.get()". The input JSON data includes challenge data issued by the FIDO service 303. The challenge corresponds to a random number and is verification data to be used in verification of user authentication using a passkey.

[0110] <url6>

[0111] https: / / mfp101.office.local / LocalUI / authentication / verification

[0112] URL6 is the URL of the REST API that receives information for passkey authentication. Receives the output JSON data output by the above API "navigator.credentials.get()". The output JSON data includes the credential ID, challenge, public key, and digital signature of the passkey used in generating the digital signature.

[0113] <Passkey Registration Sequence>

[0114] Reference Fig. 7A and Figure 7B The sequence diagram in describes the process flow related to pass key registration. Fig.10 An example of an operation screen of the mobile terminal 102 to be displayed when registering a pass key is shown. In the present exemplary embodiment, the flow of processing to be performed in the MFP 101 is recorded on a software program of the operation unit login service 301 or the FIDO service 303. The software program is stored in a nonvolatile storage device such as the ROM 202 or the HDD 204, and is loaded onto the RAM 203, and the flow of processing is executed accordingly by the CPU 201.

[0115] In step S701 , the login processing unit 302 detects that the user has pressed the pass key registration button 510 on the mobile authentication screen 501 .

[0116] In step S702, the login processing unit 302 displays a screen 505 for authenticating the user using the user ID and password on the operation panel 205. Then, the login processing unit 302 receives input of the user ID and password via the screen 505. The login processing unit 302 acquires the user ID and password input on the screen 505, and authenticates the user. Specifically, the login processing unit 302 refers to the user database stored in the HDD 204, checks the password of the user account information about the user ID that is the same as the acquired user ID using the acquired password, and in the case where the passwords are the same, determines that the user authentication has succeeded. In the case where the user authentication has failed, an error is displayed.

[0117] When user authentication has succeeded, in step S703, the login processing unit 302 generates a random number. The random number corresponds to a character string such as "52f3d66abc7519a209af9de1d96136c9", for example.

[0118] In step S704, the login processing unit 302 transmits the user ID of the user authenticated in step S702 and the generated random number to the FIDO service 303, and shares the user ID and the random number with the FIDO service 303. The transmission method can be a method using an API or a method of sharing the user ID and the random number by temporarily storing the user ID and the random number in the RAM 203 or the HDD 204. There is no specific limitation on the method of transmitting the user ID and the random number and the timing of transmitting the user ID and the random number. In addition, the random number can be generated by the FIDO service 303 or other modules instead of the login processing unit 302, and the generated random number can be shared with the login processing unit 302.

[0119] Next, in step S705, the login processing unit 302 generates a QR code and displays the generated QR code on the passkey registration screen 506. The data of the URL1 including the above random number is embedded in the QR code. The random number corresponds to information known only to those who have read the QR code image, and is intended to confirm that the user accessing the URL1 is present in front of the operation panel 205.

[0120] Next, in step S706, the user activates the camera application 313 from the mobile terminal owned by the user and reads the QR code displayed on the operation panel 205.

[0121] Next, in step S707, the camera application 313 activates the web browser 314.

[0122] In step S708, the web browser 314 accesses the address of the URL1 obtained from the QR code.

[0123] In step S709, the FIDO service 303 of the MFP 101 detects the access to the URL1. The accessed URL is verified, and if the random number obtained in step S704 is not included in the URL, an error such as HTTP 404 Not Found is transmitted to the web browser 314 as a response. If the random number obtained in step S704 is included in the URL, then in step S710, the HTML of the HTML screen 1001 for passkey registration is transmitted as a response. The HTML for passkey registration covers the JavaScript of the REST APIs for accessing the URL2 and the URL3. The HTML also covers the following JavaScript of WebAuthn defined by FIDO2.0.

[0124] <JavaScript of WebAuthn>

[0125] Output JSON data = await navigator.credentials.create(Input JSON data);

[0126] In addition, the header of the communication packet in step S710 includes the session ID to be stored in the Cookie of the web browser 314. The session ID is used to confirm that the access to URL1 where the random number in step S709 is verified and the subsequent accesses to URL2 and URL3 are made in the same session. In the case of directly accessing URL2 and URL3 without the session ID being stored in the Cookie, the FIDO service 303 may return an error without performing the requested processing.

[0127] In step S711, the web browser 314 that has received the HTML in step S710 accesses URL2 by executing JavaScript. At this time, it is desired to access URL2 by automatically executing JavaScript without the user performing web browser operations. By using the onload event of JavaScript called at the timing when the web browser 314 finishes reading the HTML of the HTML screen 1001, JavaScript can be automatically executed. Alternatively, in order to access URL2, a "Passkey Registration" button can be displayed as in the HTML screen 1002, and JavaScript can be executed when it is detected that the user presses the "Passkey Registration" button.

[0128] In step S712, the FIDO service 303 that has received the access to URL2 generates a challenge. The challenge corresponds to the random number.

[0129] Next, in step S713, the FIDO service 303 transmits the input JSON data including the generated challenge as a response. The input JSON data also includes information related to the server of the MFP 101 (e.g., the host name or domain name such as "mfp101.office.local") and the user ID.

[0130] Next, in step S714, the web browser 314 uses the received input JSON data to execute the following WebAuthn JavaScript and activates the authenticator 312.

[0131] <WebAuthn JavaScript>

[0132] Output JSON data = await navigator.credentials.create(Input JSON data);

[0133] Next, in step S715 , the authenticator 312 authenticates the owner of the mobile terminal 102 using any method of authentication using biometric information such as face authentication or fingerprint authentication, authentication using a password, and pattern authentication.

[0134] Next, in step S716, the authenticator 312 generates a key pair called a pass key (a secret key and a public key of the PKI) and a credential ID for identifying the pass key. The authenticator 312 then stores the generated key and credential ID in an anti-tampering storage area in association with information about the server of the MFP 101 (e.g., mfp101.office.local) and the user ID.

[0135] Next, in step S717, the authenticator 312 uses the generated secret key to give a digital signature to the data including the challenge data received in step S713. The authenticator 312 returns output JSON data to the web browser 314. The output JSON data includes the generated public key, the credential ID, and the digital signature.

[0136] Next, in step S718 , the web browser 314 accesses URL3 and transmits the output JSON data including the public key, credential ID, and digital signature to the FIDO service 303 .

[0137] Next, in step S719, the FIDO service 303 verifies the digital signature using the challenge issued by itself in step S712 and the received public key. Specifically, by using the received public key to decode the digital signature, the FIDO service 303 verifies whether the digital signature is the same as the challenge issued by itself. In the case where the digital signature is the same as the challenge, it is determined that the verification of the digital signature has succeeded. In the case where the digital signature is not the same as the challenge, it is determined that the verification of the digital signature has failed. In the case where the verification of the digital signature has succeeded, then in step S720, the FIDO service 303 stores the pass key information (public key and credential ID) and the user ID in the user database in the HDD 204 in association with each other.

[0138] Next, in step S721, the FIDO service 303 transmits a response to the web browser 314 indicating whether the pass key registration has succeeded.

[0139] Next, in step S722 , the FIDO service 303 transmits a pass key registration completion notification to the login processing unit 302 .

[0140] Next, in step S723, the login processing unit 302 displays a screen 507 for selecting whether to invalidate the password authentication on the operation panel 205. In the case where it is detected that the user has selected "Yes", the login processing unit 302 stores the invalidation of the password authentication in association with the user ID in the user database in the HDD 204. Control is performed in such a manner that the user who has invalidated the password authentication cannot perform login using the user ID and password thereafter and can log in to the operation panel 205 only by mobile authentication (passkey authentication).

[0141] Finally, in step S724, the login processing unit 302 closes the pass key registration screen and ends the pass key registration process.

[0142] In the above configuration, an example is described in which a user who attempts to register a passkey is authenticated on the operation panel 205. The user may be authenticated on the web browser 314 of the mobile terminal 102. In this case, in step S710, the HTML screen 1003 to be returned by the FIDO service 303 includes a text field for inputting a user ID and a password, and prompts the user to input the user ID and password. In addition, the FIDO service 303 receives the user ID and password input by the user using the packet in step S711, and authenticates the user by referring to the user database in the HDD 204.

[0143] Validation / invalidation of password authentication for each user, check of the registration status of the pass key, and deletion of the registration of the pass key can be performed on the user account editing screen 603. The user account editing screen 603 is a screen that can be browsed and edited by a user serving as an administrator user assigned the role of an administrator having authority to change the management settings of the MFP 101. If the operation unit login service 301 authenticates the administrator user assigned the role of the administrator, the operation unit UI service 304 displays the menu screen 503. If the operation unit UI service 304 receives a selection of the management settings on the menu screen 503, the operation unit UI service 304 displays the management settings screen 504. Then, if the operation unit UI service 304 receives a selection of "user account management" on the management settings screen 504, the operation unit UI service 304 displays the user account management screen 602. On the user account management screen 602, the administrator user selects a user whose account is desired to be edited, and presses the edit button. If the operation unit UI service 304 detects the pressing of the edit button, the operation unit UI service 304 displays the user account edit screen 603 of the selected user. If the operation unit login service 301 authenticates the general user to whom the role of the general user has been assigned, the operation unit UI service 304 displays the menu screen 503, but controls in such a manner that the selection of the management setting is not received. Therefore, the general user cannot browse the user account management screen 602. The general user can press the "personal settings" button displayed on the menu screen 503. If the operation unit UI service 304 detects the pressing of the "personal settings" button, the operation unit UI service 304 displays the user account edit screen 603 of the account of the general user who logged in.

[0144] On the user account editing screen 603, by pressing the validation button 604, the invalidated password authentication can be validated again. In the case of "the pass key has been registered" and "validate the password authentication", the invalidate button is displayed instead of the validation button 604, so that the password authentication can be invalidated. If the "password authentication" is invalidated in the case of "the pass key has not been registered", the user cannot perform the login. Therefore, in the case of "the pass key has not been registered", the invalidation of the "password authentication" can be made inexecutable. In the case where the pass key has been registered, the registration of the pass key can be deleted by pressing the registration deletion (deregistration) button 605. If the pass key registration is deleted, the user becomes unable to use the pass key to perform the login, and it is expected that the invalidated password authentication is automatically validated.

[0145] When the pass key has not been registered, “unregistered” is displayed as the pass key registration state. When the pass key has not been registered, the registration deletion button 605 is displayed in a gray state or is hidden.

[0146] <Passkey Authentication Sequence>

[0147] Reference Fig. 8A and Figure 8B The sequence diagram in describes the process of logging in using a pass key.

[0148] Fig.11 An example of an operation screen to be displayed on the mobile terminal 102 at the time of passkey authentication is shown.

[0149] In step S801, in a case where the user has not yet performed login, the login processing unit 302 starts display of the mobile authentication screen 501. For example, if the logged-in user performs logout, the login processing unit 302 displays the mobile authentication screen 501. In addition, the login processing unit 302 may be configured to display the mobile authentication screen 501 when the power of the MFP 101 is turned on.

[0150] In step S802, the login processing unit 302 generates a random number. The random number corresponds to a character string such as "b15dee080a1a549be6e3c74e6b59f5c5", for example.

[0151] Next, in step S803, the login processing unit 302 transmits the generated random number to the FIDO service 303 and shares the random number with the FIDO service 303. The transmission method may be a method using an API or a method of sharing the random number by temporarily storing the random number in the RAM 203 or the HDD 204. There is no specific limitation on the method for transmitting the random number and the timing of transmitting the random number. The random number may be generated by the FIDO service 303 or other modules instead of the login processing unit 302, and the generated random number may be shared with the login processing unit 302.

[0152] Next, in step S804, the login processing unit 302 generates a QR code, and performs display control in such a manner that the generated QR code is displayed on the mobile authentication screen 501. The data of URL4 including the above-mentioned random number is embedded in the QR code. The random number corresponds to information known only to a person who has read the QR code image, and is intended to confirm that the user who accesses URL4 is present in front of the operation panel 205.

[0153] Next, in step S805 , the user activates the camera application 313 from the mobile terminal owned by the user himself / herself, and reads the QR code displayed on the operation panel 205 .

[0154] Next, in step S806 , the camera application 313 activates the web browser 314 .

[0155] Next, in step S807, the web browser 314 accesses the address of the URL4 obtained from the QR code.

[0156] In step S808, the FIDO service 303 of the MFP 101 detects the access to the URL4. The accessed URL is verified, and in the case where the random number obtained in step S803 is not included in the URL, an error such as HTTP 404 Not Found is transmitted to the web browser 314 as a response. In the case where the random number obtained in step S803 is included in the URL, then in step S809, the HTML of the HTML screen 1011 for passkey authentication is transmitted as a response. The HTML for passkey authentication covers the JavaScript of the REST APIs for accessing the URL5 and URL6. The HTML also covers the following JavaScript of WebAuthn defined by FIDO2.0.

[0157] <JavaScript of WebAuthn>

[0158] Output JSON data = await navigator.credentials.get(Input JSON data);

[0159] In addition, the header of the communication packet in step S809 includes the session ID to be stored in the Cookie of the web browser 314. The session ID is used to confirm that the access to the URL4 where the random number in step S808 is verified and the subsequent accesses to the URL5 and URL6 are made in the same session. In the case of directly accessing the URL5 and URL6 without the session ID being stored in the Cookie, the FIDO service 303 can return an error without performing the requested processing.

[0160] In step S810, the web browser 314 accesses the address of the URL5. At this time, it is expected to access the URL5 by automatically executing JavaScript without the user operating the web browser. By using the onload event of the JavaScript called at the timing when the web browser 314 finishes reading the HTML of the HTML screen 1011, the JavaScript can be automatically executed.

[0161] Alternatively, a "Passkey Authentication" button as shown in the HTML screen 1012 can be displayed, and the JavaScript can be executed when it is detected that the user presses the "Passkey Authentication" button, thereby allowing access to the URL5.

[0162] In step S811, the FIDO service 303 that has received an access to URL5 generates a challenge. The challenge corresponds to a random number.

[0163] Next, in step S812, the FIDO service 303 transmits the input JSON data including the generated challenge as a response. The input JSON data also includes information related to the server of the MFP 101 (e.g., a host name or a domain name such as "mfp101.office.local").

[0164] Next, in step S813, the web browser 314 executes the following WebAuthn JavaScript using the received input JSON data and activates the authenticator 312. In the case where the authenticator 312 manages multiple passkeys in association with information related to the server of the MFP 101, in some cases, a screen for selecting one passkey from multiple passkeys may be displayed.

[0165] <WebAuthn JavaScript>

[0166] Output JSON data = await navigator.credentials.create(input JSON data);

[0167] Next, in step S814, the authenticator 312 authenticates the owner of the mobile terminal 102 using any method of face authentication, fingerprint authentication, password authentication, and pattern authentication.

[0168] Next, in step S815, the authenticator 312 obtains the passkey (the secret key of PKI) stored in association with information related to the server of the MFP 101 (e.g., mfp101.office.local). Then, a digital signature is generated using the secret key for the data including the challenge received in step S812. The authenticator 312 returns the output JSON data to the web browser 314. The output JSON data includes the digital signature and the credential ID of the passkey used for generating the digital signature.

[0169] Next, in step S816, the web browser 314 accesses URL6 and transmits the output JSON data including the public key, the credential ID, and the digital signature to the FIDO service 303.

[0170] Next, in step S817, the FIDO service 303 refers to the user database in the HDD 204 and obtains the user ID and the public key of the account associated with the received credential ID.

[0171] Next, in step S818, using "the challenge issued by the FIDO service 303 itself in step S811" and "the public key obtained from the user database in step S817", the FIDO service 303 verifies "the digital signature received in step S816". Specifically, by decoding the digital signature using the public key, the FIDO service 303 verifies whether the digital signature is the same as the challenge issued by the FIDO service 303 itself. In the case where the digital signature is the same as the challenge and the verification of the digital signature has succeeded, it is determined that the authentication has succeeded. In the case where the verification has failed, it is determined that the authentication has failed.

[0172] Next, in step S819 , the FIDO service 303 transmits a response indicating whether the authentication has succeeded.

[0173] In the case where the authentication has succeeded, then in step S820, a request to log in to the operation panel 205 is transmitted to the log-in processing unit 302. The log-in request includes the user ID.

[0174] Next, in step S821, the login processing unit 302 performs a login process for allowing the user having the user ID specified in step S820 to log in to the operation panel 205. Specifically, referring to the user database in the HDD 204, the login processing unit 302 acquires user information such as the user ID, role, and email address of the account being logged in. In addition, the login processing unit 302 notifies the operation unit UI service 304 of a login occurrence event. The login occurrence event includes information related to the user being logged in.

[0175] Finally, in step S822, the login processing unit 302 closes the mobile authentication screen 501, the operation unit UI service 304 displays the menu screen 503, and the login processing ends. If the authentication has succeeded in step S818, the operation unit UI service 304 provides the user with a function premised on user authentication. The function premised on user authentication to be provided when the authentication has succeeded is described above in the description of the user authentication function.

[0176] In step S817, in the case where verification has not succeeded, the FIDO service 303 transmits a failure notification in step S819. Examples of such a case include a case where "the designated user ID is not registered in the user database", a case where "the public key of the passkey is not registered in association with the user ID", and a case where "verification of the digital signature has failed" in step S818. Alternatively, the FIDO service 303 may notify the login processing unit 302 of an error, and an authentication failure message may be displayed on the mobile authentication screen 501. In the case where "the designated user ID is not registered in the user database", or in the case where "the public key of the passkey is not registered in association with the user ID", the FIDO service 303 cannot identify the public key to be used in the verification in step S818. Thus, the failure notification may be transmitted in step S819 without performing the verification in step S818.

[0177] When the authentication success notification or the authentication failure notification is received, it is desirable to update the random number to be stored in the QR code on the mobile authentication screen 501 to a new random number. For security reasons, even when the authentication success notification or the authentication failure notification is not received, it is desirable to shorten the life of the random number by periodically updating the random number.

[0178] In the above configuration, an example is described in which the web browser 314 that has completed receiving the HTML of the HTML screen 1011 in step S809 automatically executes JavaScript using the onload event of JavaScript. In step S809, as in the HTML screen 1012, a pass key authentication button may be included, and the user may be prompted to press the pass key authentication button.

[0179] In step S809, as shown in HTML screen 1013, a text field for inputting a user ID may be included, and the user may be prompted to input the user ID. In this case, URL 5 to be accessed in step S810 includes the user ID. The FIDO service 303 having received this may obtain the credential ID associated with the user ID from the user database, and include the credential ID in the response to be transmitted in step S812. With this configuration, even if a plurality of pass keys are managed on the authenticator 312 side, it is possible to narrow down to one pass key to be used based on the credential ID.

[0180] <Sequence of Pass Key Registration and Authentication to be Executed When Validating Simple Login>

[0181] Reference Fig.15A and Fig. 15B The flowchart in FIG. 1 describes the processing flow until the pass key registration and authentication to be performed when the simple login is enabled. For example, when the logged-in user performs a logout, the process starts Fig.15A and Fig. 15B Furthermore, if the power of the MFP 101 is turned on, the processing starts.

[0182] In step S1501, the login processing unit 302 checks whether the validation button 1402 for “validating simple login” has been set on the simple login setting screen 1401. When the simple login is validated, the login processing unit 302 starts processing for displaying the simple login screen 1301.

[0183] In step S1502, the login processing unit 302 refers to the user database in the HDD 204 and checks the account information to be displayed on the simple login screen 1301. The login processing unit 302 checks whether the password authentication is invalidated for all users. If the password authentication is invalidated ("Yes" in step 1502), the process proceeds to step S1503. On the other hand, if the password authentication is not invalidated ("No" in step S1502), the process proceeds to step S1504. In step S1503, the password authentication button is hidden.

[0184] After executing the process for displaying the simple login screen 1301, in step S1504, the login processing unit 302 detects pressing of the user avatar.

[0185] Next, in step S1505, account information such as the user ID and role associated with the user avatar is temporarily stored. The method of temporarily storing the account information may be a method using an API or a method of storing the account information in an area of ​​the RAM 203. The storage method and storage timing are not particularly limited.

[0186] Next, in step S1506, the login processing unit 302 checks the setting 1403 for the authentication method enforcement for each role on the simple login setting screen 1401. Fig.14 As shown, when the role of the user who performs simple login is "Administrator" or "General User", the setting of forcing FIDO authentication can be performed. When the role of the user is "Limited User", the setting of not forcing the authentication process after simple login can be performed. For all roles, the administrator who performs the simple login setting can force FIDO authentication, or can set not to perform authentication after simple login.

[0187] Next, in step S1507 , the login processing unit 302 determines processing to be performed after the simple login authentication based on the temporarily stored role information and the setting 1403 for authentication method enforcement for each role.

[0188] For example, in the case where authentication of the user "Dave" shown in the user database 401 is to be performed, because the setting of FIDO authentication enforcement is set to a non-enforced state ("FIDO AUTHENTICATION ENFORCEMENT UNEXECUTED"), the processing proceeds to step S1508. In step S1508, the login processing unit 302 checks the pass key registration state of the user "Dave" to be authenticated. Because the pass key registration state of the user "Dave" to be authenticated is an unregistered state ("Yes" in step S1508), the processing proceeds to step S1509. In step S1509, the login processing unit 302 checks whether the user "Dave" to be authenticated is a user who performs his / her first login. In the case where the user is not a user who performs his / her first login ("No" in step S1509), the login processing unit 302 performs only simple login authentication, and the processing proceeds to step S1521. In step S1521, the login processing ends. In the case where the user is a user who performs his / her first login ("Yes" in step S1509), in step S1510, the login processing unit 302 performs processing for displaying the registration screen 1306 for prompting the user to perform pass key registration before the authentication processing is performed. In step S1511, it is determined whether the logged-in user performs pass key registration. In the case where it is determined that the logged-in user performs pass key registration ("Yes" in step S1511), the processing proceeds to step S1512. In step S1512, the login processing unit 302 performs the above-mentioned pass key registration processing in steps S703 to S724. Then, in step S1521, the login processing unit 302 performs the login processing. In the case where the logged-in user does not perform pass key registration ("No" in step S1511), the processing proceeds to step S1521. In step S1521, the login processing unit 302 performs only simple login authentication, and the login processing ends.

[0189] In the case where authentication of the user "Carol" shown in the user database 401 is to be performed, the setting for enforcing FIDO authentication is set to the mandatory state, but the pass key registration has not yet been performed ("FIDO AUTHENTICATION FORCED AND PASSKEY UNREGISTERED"). Therefore, in step S1513, the login processing unit 302 performs processing for displaying the pass key registration screen 1305 before performing the authentication processing. Next, in step S1514, in a case where it is determined that the logged-in user performs pass key registration ("Yes" in step S1514), the processing proceeds to step S1516. In step S1516, the login processing unit 302 performs the above-mentioned pass key registration processing in steps S703 to S724. After performing the pass key registration processing, the login processing unit 302 performs the login processing shown in step S1521, and the processing ends. In a case where the login user does not perform pass key registration (No in step S1514), the process proceeds to step S1515. In step S1515, the login processing unit 302 cancels the simple login authentication process and performs a process for displaying a pass key not registered error screen.

[0190] In the case where authentication of the user "Alice" shown in the user database 401 is to be performed, since the setting for FIDO authentication enforcement is set to the mandatory state and the pass key registration has been performed ("FIDO AUTHENTICATION FORCED AND PASSKEY REGISTERED"), the processing proceeds to step S1517. In step S1517, the login processing unit 302 performs processing for displaying the mobile authentication screen 1302. After performing the display processing for displaying the mobile authentication screen 1302, in step S1518, the login processing unit 302 performs the above-mentioned pass key authentication processing in steps S802 to S818.

[0191] Here, in Fig. 15B In step S818, the FIDO service 303 performs verification of the digital signature using the public key corresponding to the user who has performed the simple login authentication. In step S817, in the case that "the public key of the passkey is not registered in association with the user ID", or in the case that "the public key is registered but the user ID is different from the user ID of the user who has performed the simple login authentication" ("No" in step S1519), in step S1520, a failure notification is transmitted without performing the verification in step S818. In the case that the verification has not succeeded in step S818 due to a reason such as "the verification of the digital signature has failed" ("No" in step S1519), in step S1520, a failure notification is transmitted. The login processing unit 302 may also perform an error notification, and may display an authentication failure message on the mobile authentication screen 501. In the case that the authentication has failed ("No" in step S1519), the login processing unit 302 cancels the simple login authentication processing, and in step S1520, performs processing for displaying an error screen that the public key is not the same. In a case where the authentication has succeeded (YES in step S1519), the login processing unit 302 executes the login processing shown in step S1521, and the processing ends.

[0192] <Effect>

[0193] Since the present exemplary embodiment allows the user to log in to the operation panel using the biometric authentication function of the mobile terminal owned by the user, password-free login can be provided without the additional cost of an IC card reading device. This is also safe because a digital signature verification technology using a pass key also used in FIDO is used. In the present exemplary embodiment, verification of the image forming apparatus can be performed without the need for an external FIDO server.

[0194] According to the present exemplary embodiment, a method of invalidating password authentication for a user who has registered a passkey is provided. By invalidating password authentication, security-related concerns such as password brute force attacks and password leaks can be eliminated, thereby providing a secure login method.

[0195] In addition, according to the present exemplary embodiment, the mobile terminal has the function of reading the QR code using the camera of the mobile terminal, activating the standard browser, and accessing the URL embedded in the QR code. Thus, a dedicated mobile application is not required, and the function can be used only by the standard camera and the standard browser set in the mobile terminal.

[0196] In the first exemplary embodiment, an example using a standard camera and a standard browser provided in a mobile terminal is described.

[0197] As a second exemplary embodiment, Fig. 9 As shown, a vendor may provide an MFP application 901 that may be installed on the mobile terminal 102 . Fig.12 An operation screen of the mobile terminal 102 to be displayed when the MFP application 901 is used is shown.

[0198] The MFP application 901 includes a WebView (Web view) 902. The WebView 902 is a component having a function equivalent to that of a web browser. The MFP application 901 can also store the address of the MFP 101 and the user ID in a storage area of ​​the MFP application 901 in advance.

[0199] The MFP application 901 activates the camera and displays a QR code reading button on the screen 1201. The MFP application 901 detects the pressing of the QR code reading button and then reads the QR code. Next, if the MFP application 901 obtains an address from the QR code, the MFP application 901 activates WebView 902 (screen 1202). WebView 902 accesses the address obtained from the QR code. At this time, the user ID pre-registered in the MFP application 901 is transmitted. In the first exemplary embodiment, WebView 902 plays the role of the web browser 314 in the process of processing from step S806 to S819. Finally, it is expected that the MFP application 901 detects the reception of the response in step S819 and closes WebView 902.

[0200] Alternatively, the user may be prompted to select an MFP from among the MFPs on the screen 1203 of the MFP application 901 , and a URL of an address stored in association with the selected MFP may be accessed from the WebView 902 .

[0201] A configuration may be adopted to confirm the user's presence in front of the MFP 101 using a personal identification number (PIN) code. The PIN code corresponds to a random number. In this case, in step S804, the random PIN code is displayed on the mobile authentication screen 501. In step S809, it is expected that an HTML screen 1204 including a text field for PIN code input is returned, and the user is required to enter the PIN code that the user has visually checked on the mobile authentication screen 501 on the HTML screen 1202.

[0202] Alternatively, the user may be prompted to select an MFP from among the MFPs on the screen 1205 of the MFP application 901, and pass key authentication may be performed without requiring QR code reading and PIN code input. In this case, since it is not possible to confirm whether there is a user performing mobile operation in front of the MFP 101, the user is permitted to log in to the operation panel 205 of the MFP 101 from a remote location.

[0203] In the first exemplary embodiment, a configuration in which a digital signature verification technology (FIDO service) is provided in an image forming device is described. In this case, when there are multiple image forming devices in an office and users use multiple image forming devices, a public key (pass key) is registered with each image forming device. In order to solve this problem, in a third exemplary embodiment, a configuration in which a digital signature verification technology (FIDO service) is provided outside the image forming device will be described. In the third exemplary embodiment, the digital signature verification technology (FIDO service) provided outside the image forming device is used to authenticate a user who uses the image forming device so as to allow the user to use the image forming device.

[0204] <System Configuration>

[0205] Reference Fig.16 A system configuration according to the present exemplary embodiment is described. An MFP 101 is an MFP to which the present invention is applied. A mobile terminal 102 is a user terminal owned by a user of the MFP 101 and is a mobile terminal such as a smartphone or the like.

[0206] The MFP login server 105 is a cloud service having a server function accessible from the Internet. The MFP login server 105 may be an on-premises server connected to a LAN instead of a cloud service. The function of the MFP login server 105 may be implemented by a plurality of servers instead of a single server. The present invention is not limited to a cloud service, but the present exemplary embodiment will be described assuming that the MFP login server 105 is a cloud service.

[0207] The MFP 101 and the mobile terminal 102 can each communicate with the MFP login server 105 via the Internet. The MFP 101 installed in the office can be connected to the MFP login server 105 via a LAN or a proxy server built in the office. Alternatively, the MFP 101 can be directly connected to the Internet and connected to the MFP login server 105. The mobile terminal 102 used in the office can be connected to the MFP login server 105 via a wireless LAN in the office. Alternatively, the mobile terminal 102 can be directly connected to a mobile network such as the fourth generation (4G) or the fifth generation (5G), and connected to the MFP login server 105. It is assumed that there are multiple MFPs (not shown) connected to the MFP login server 105 and multiple mobile terminals of users (not shown).

[0208] The hardware configuration of the MFP 101 is Figure 2A The hardware configuration of the mobile terminal 102 is similar to that of the first exemplary embodiment shown in FIG. Figure 2B The configuration according to the first exemplary embodiment shown is similar.

[0209] Fig.17 1 is a schematic diagram showing the hardware configuration of a general-purpose computer for realizing the MFP login server 105 .

[0210] The CPU 1701 executes the programs stored in the ROM 1702 and the programs of the OS and applications loaded from the storage device 1710 to the RAM 1703. That is, by executing the programs stored in the readable storage medium, the CPU 1701 functions as each processing unit for performing the processing of each sequence described below. The RAM 1703 is the main memory of the CPU 1701 and is used as a work area. The keyboard controller 1704 controls the operation input from the keyboard 1708 or the pointing device (not shown) (mouse, touch pad, touch panel, trackball, etc.). The display controller 1705 controls the display on the display 1709. The disk controller 1706 controls data access to the hard disk drive (HDD) storing various types of data and the storage device 1710 such as a flash memory. The communication unit 1707 is a network interface that is connected to the network and performs control processing of communication with other devices connected to the network. In the case where the server is constructed as a virtual server, since the operation is performed from a remote location, it is not always necessary to provide the keyboard 1708 and the display 1709. In addition, a storage device that can be connected to a network that can communicate with the communication unit 1707 may be used instead of the storage device 1710 .

[0211] <Software Configuration>

[0212] Fig.18 1 is a schematic diagram showing the software configuration of the MFP 101, the mobile terminal 102, and the MFP login server 105. Figure 2A and Figure 2B Software modules equivalent to the software modules according to the first exemplary embodiment shown in FIG. 1 are assigned the same reference numerals, and description thereof will be omitted.

[0213] The operating unit login service 301 includes a cloud communication unit 308 for communicating with an external FIDO service 321 instead of Figure 3 FIDO service 303 is shown. The operating unit login service 301 may include both the FIDO service 303 and the cloud communication unit 308. In order to receive messages from the MFP login server 105, the cloud communication unit 308 establishes a WebSocket connection with the MFP login server 105. The present invention is not limited to the use of WebSocket, and different technologies can be used as long as the message can be transmitted from the MFP login server 105 to the MFP 101. For example, different technologies such as Message Queuing Telemetry Transport (MQTT), polling, or WebPush can be used.

[0214] The FIDO service 321 of the MFP login server 105 has a web server function that enables HTTP-compliant communication. The FIDO service 321 also has an authentication function of WebAuthn defined by the FIDO Alliance or W3C. The FIDO service 321 also has a function as an identity provider (Identity Provider, IdP) for managing the accounts of users who use the operation panel (operation unit) of the MFP 101. The FIDO service 321 includes a website and a database for registering and managing account information related to the user as an IdP. A configuration for managing user accounts in collaboration with an IdP provided by a third party supplier such as Microsoft Corporation or Google LLC can be adopted. The MFP management service 322 includes a website and a database for registering and managing MFPs connected to the MFP login server 105.

[0215] MFP login server 105 can have the function of managing MFP and user account in each office for each tenant based on the contract with the company office. In this case, only the user who is given authority for each tenant can manage MFP and MFP user account on the website of MFP login server 105.

[0216] In addition, the MFP login server 105 can manage MFPs installed in public spaces such as convenience stores and accounts of individual users who use the MFPs. In this case, the administrator of the MFP registers information related to the MFP with the MFP management service 322. Individual users register their own accounts in the FIDO service 321 based on a contract. It is considered that the MFPs and functions of the MFPs that can be used by individual users are determined based on the contract.

[0217] <User Account>

[0218] Fig.19 It is a schematic diagram showing the account information managed by the FIDO service 321. In the account information 1901, the user ID, the passkey information (credential ID and public key) to be used in FIDO authentication, the role, and the email address are recorded.

[0219] The "user ID" is an identifier for identifying the user. The "role" is information indicating the usage permission of the user for the MFP 101. Examples of each role and usage permission are shown in the role information table 1902. In addition to the definition of the default role, it is also possible to enable the user to create a new role by setting detailed usage permissions.

[0220] Table 1903 indicates the association between the user and the MFPs that the user can use.

[0221] <MFP Management Information>

[0222] Fig. 20 It is a schematic diagram showing the MFP management information 2001 managed by the MFP management service 322. The "MFP-ID" is an identifier for uniquely identifying the MFP. That is, the "MFP-ID" is identification information related to the MFP. The "MFP-ID" can be any information as long as the "MFP-ID" of a certain MFP does not overlap with the IDs of other MFPs. For example, the serial number of the MFP or the host name in the fully qualified domain name (FQDN) format can be used. In the case of communicating with the MFP using MQTT, the client ID used in the MQTT communication can be used as the MFP-ID. In addition, the MFP management service 322 can issue the MFP-ID at the time of MFP registration and can register the MFP-ID with the MFP. The "online status" indicates the connection status with each MFP. For example, in the case where a WebSocket connection is established between the MFP and the MFP login server 105, it indicates "online", and in the case where the connection is not established, it indicates "offline".

[0223] The "operation unit status" indicates the usage status of the operation panel of the MFP. It indicates "ready" when no one is in the logged-in state. It indicates "logged in" when someone is in the logged-in state and using the operation panel.

[0224] <Login Settings of MFP>

[0225] Next, reference will be made to Fig.21 、 Fig. 22 和 Fig.23 to describe the collaborative operations to be performed by the MFP 101 and the MFP login server 105.

[0226] Fig.21 和 Fig. 22 It is a schematic diagram showing an example of a user interface to be displayed on the operation panel 205 of the MFP 101. Fig.23 It is a schematic diagram showing the communication between the MFP 101 and the MFP login server 105.

[0227] The menu screen 2101 is displayed on the operation panel 205 before the login settings are executed.

[0228] If the pressing of the management settings button on the menu screen 2101 is detected, the management settings screen 2102 is displayed on the operation panel 205. When the management settings button is pressed, an authentication screen (not shown) for inputting a user name and password may be displayed to authenticate the administrator. The management settings screen 2102 is the portal screen in the management settings. The administrator of the MFP 101 can perform various settings related to the MFP 101, such as "network settings", "function settings", and "login server settings", etc. If the "login server settings" button is pressed on the management settings screen 2102, the login server settings screen 2103 is displayed. The login server settings screen 2103 is a settings screen for validating the login function of the MFP 101. For example, the administrator of the MFP 101 validates the function of collaborating with the MFP login server by inputting the "server address of the MFP login server" and the "MFP-ID" on the login server settings screen 2103. In addition, since the client certificate for identifying the MFP is processed on the login server settings screen 2103, the following functions are provided.

[0229] - Generation of a key pair

[0230] - Creation of a request for issuing a client certificate (public key certificate) (certificate signing request). The client certificate includes the MFP-ID.

[0231] - Importing the client certificate issued by a Certificate Authority (CA) from an external memory medium.

[0232] <Connection between the MFP and the MFP login server>

[0233] The MFP 101 that validates the function of collaborating with the MFP login server attempts to connect to the MFP login server 105 using the WebSocket protocol.

[0234] Specifically, in Fig.23 In step S2301 shown, the cloud communication unit 308 of the MFP 101 transmits a WebSocket connection request to the MFP login server 105. At this time, the MFP 101 performs a Transport Layer Security (TLS) handshake and transmits a client certificate and a digital signature to the MFP login server 105.

[0235] In step S2302, the MFP registration server 105 authenticates the MFP by verifying the received client certificate and digital signature to prevent MFP impersonation. To confirm that the MFP is the MFP managed in the table 1903 of the MFP management information, it is confirmed whether the MFP-ID acquired from the client certificate is registered in the MFP management information 2001.

[0236] In the case where the authentication of the device has succeeded, then in step S2303, the MFP login server 105 returns a WebSocket connection response to the MFP 101. Thereafter, the MFP 101 and the MFP login server 105 become able to transmit messages to each other using the WebSocket connection. The MFP login server 105, which has detected that the connection with the MFP 101 has been established, changes the "online status" in the MFP management information 2001 from "offline" to "online". In the case where the authentication of the device has failed, the MFP login server 105 may reject the WebSocket connection request from the MFP 101.

[0237] In step S2304, the MFP 101 having received the WebSocket connection response displays on the operation panel 205 Fig. 22 The login screen 2201 shown is displayed, and the use of the operation panel 205 is restricted in such a manner that the menu screen and various functions cannot be used unless the login is performed.

[0238] <Login instruction from MFP login server>

[0239] The user's login is performed in collaboration by the operation unit login service 301, the mobile terminal 102, and the MFP login server 105. The MFP login server 105 authenticates the user by using a technology called a pass key defined by PKI in FIDO. The registration of the pass key and the authentication sequence using the pass key will be described in detail below. In the present exemplary embodiment, the authentication of the user performed by the MFP login server 105 by using a technology utilizing the PKI defined by FIDO will be referred to as user authentication. That is, authenticating the user based on the result obtained by using a public key to verify the signature data obtained by encrypting the challenge using a secret key will be referred to as user authentication. In the present exemplary embodiment, in addition to the user authentication, authentication for authenticating the owner of the mobile terminal is performed in the mobile terminal. These authentications correspond to the authentication in step S2619 and the authentication in step S2714 to be described below. In this way, in the present exemplary embodiment, there are multiple types of authentications.

[0240] In the case where user authentication in the MFP login server 105 has succeeded, in step S2305, the MFP login server 105 transmits user information about the target account for which login to the MFP 101 is to be performed. The user information includes information such as a user ID, an e-mail address, a role, and authority stored in the account information 1901. The user information may be transmitted and received in a text format such as JSON.

[0241] In step S2306 , the cloud communication unit 308 of the MFP 101 transmits the received user information to the login processing unit 302 , and the login processing unit 302 performs login processing.

[0242] After the login processing is completed, in step S2307, the cloud communication unit 308 of the MFP 101 transmits a login completion notification to the MFP login server 105. The MFP login server 105 changes the operation unit status in the MFP management information 2001 from “ready” to “logged in”.

[0243] If the login has succeeded, the operation unit UI service 304 that has detected the login of the user displays the menu screen 2202 on the operation panel 205. Then, the operation unit UI service 304 provides functions premised on user authentication. Control is performed in such a way that a button for a function for which the user has not been given authority is displayed in a gray state so that the function cannot be used.

[0244] Examples of functions that presuppose user authentication include a printing function to be executed by the printer 206 with a predetermined print setting. In the case where a user assigned the role of an administrator or general user is authenticated, printing with a color print setting becomes executable. In the case where a user assigned the role of a limited user is authenticated, only printing with a monochrome print setting is permitted. For example, in the case where a user assigned the role of a general user has logged into the MFP 101, the "Management Settings" button on the menu screen 2202 is displayed in a grayed-out state. In the case where a user who does not have the authority to use the address book has logged into the MFP 101, the address book reference button on the scan and send screen 2203 is displayed in a grayed-out state.

[0245] Examples of functions premised on user authentication also include a function of transmitting, to an external device, image data obtained by scanning performed by the scanner 207. This function is provided to a user assigned a role of an administrator or a general user when the user is authenticated.

[0246] Examples of functions that presuppose user authentication also include a function of using an address book when specifying a transmission destination of image data obtained by scanning performed by the scanner 207. The address book is a list in which information related to one or more transmission destinations is registered. A user assigned the role of a general user can specify a transmission destination of image data by selecting a transmission destination from the address book. A user assigned the role of an administrator can register a new transmission destination on the address book or edit the address book in addition to being able to select a transmission destination from the address book.

[0247] Examples of functions that presuppose user authentication also include functions for making settings for the MFP 101. When displayed on the management setting screen 504, the settings for the MFP 101 include operation unit UI login method settings, settings related to each user account, device settings, and network settings. In a case where a user assigned the role of administrator is authenticated, these setting functions are provided to the user, and the user can make any of the settings for the MFP 101. The device settings include settings related to a print job or a scan job, such as a setting indicating whether a history to be recorded in job execution is to be displayed on the operation panel 205. The network settings include settings such as a setting indicating whether to permit the use of each printing protocol in printing.

[0248] Upon detecting that the user has performed a logout operation on the operation panel 205 , in step S2308 , the login processing unit 302 of the MFP 101 performs a logout process and displays the login screen 2201 again.

[0249] After the logout process, in step S2309, the cloud communication unit 308 of the MFP 101 transmits a logout notice to the MFP login server 105. The MFP login server 105 changes the operation unit status in the MFP management information 2001 from "logged in" to "ready".

[0250] <FIDO Service Function>

[0251] The FIDO service 321 has a web server function that enables HTTP-compliant communication. The FIDO service 303 also has an authentication function for WebAuthn defined by the FIDO Alliance or the W3C.

[0252] The web browser 314 of the mobile terminal 102 that has read the QR code displayed on the login screen 2201 or the passkey registration screen 2206 accesses the FIDO service 321 via HTTPS communication. The FIDO service 321 provides access and functions to, for example, the following URLs 1 to URL 6 as a web server.

[0253] <url1>

[0254] https: / / mfplogin.service.com / registration

[0255] URL1 returns the HTML for obtaining the user ID's HTML screen, the HTML for identifying the user using the password, or the HTML for passkey registration.

[0256] The HTML for passkey registration returned by URL1 covers the JavaScript for accessing the REST APIs of the following URL2 and URL3. The HTML also covers the JavaScript of the following WebAuthn defined by FIDO2.0.

[0257] <JavaScript of WebAuthn>

[0258] Output JSON data = await navigator.credentials.create(Input JSON data);

[0259] <url2>

[0260] https: / / mfplogin.service.com / registration / challenge

[0261] URL2 is the URL of the REST API that returns the input JSON data to be input to the above-mentioned API "navigator.credentials.create()". The input JSON data includes the challenge data issued by the FIDO service 321. The challenge corresponds to a random number and is verification data to be used in verification for passkey registration.

[0262] <url3>

[0263] https: / / mfplogin.service.com / registration / verification

[0264] URL3 is the URL of the REST API for receiving information for passkey registration. Receive the output JSON data output by the above API "navigator.credentials.create()". The output JSON data includes the credential ID, challenge, public key and digital signature issued by the mobile terminal 102.

[0265] <url4>

[0266] https: / / mfplogin.service.com / authentication?random=random numbers&MFP-ID=the MFP 101

[0267] URL4 is the URL that returns the HTML for passkey authentication. URL4 can specify a random number and MFP-ID as URL parameters. The random number corresponds to a string such as "b15dee080a1a549be6e3c74e6b59f5c5", for example. The random number is the same as the string to be embedded in the QR code on the login screen 2201. In the case where passkey authentication has been successful, the MFP-ID indicates the MFP that the user is to log in to.

[0268] The HTML for passkey authentication returned by URL4 covers JavaScript for accessing the REST APIs for the following URLs 5 and 6. The HTML also covers the following WebAuthn JavaScript defined by FIDO2.0.

[0269] <WebAuthn JavaScript>

[0270] Output JSON data = await navigator.credentials.get(Input JSON data);

[0271] <url5>

[0272] https: / / mfplogin.service.com / authentication / challenge

[0273] URL5 is the URL of the REST API that returns the above-mentioned input JSON data to be input to the above-mentioned "navigator.credentials.get()". The input JSON data includes challenge data issued by the FIDO service 321. The challenge corresponds to a random number and is verification data to be used in verification of user authentication using a passkey.

[0274] <url6>

[0275] https: / / mfplogin.service.com / authentication / verification

[0276] URL6 is the URL of the REST API that receives information for passkey authentication. The output JSON data output by the above API "navigator.credentials.get()" is received. The output JSON data includes the credential ID of the passkey used in generating the digital signature, the challenge, and the digital signature.

[0277] Fig.24 1 is a flowchart showing the flow of processing to be executed by the CPU 201 of the MFP 101 in the above-mentioned cooperation between the MFP 101 and the MFP login server 105 .

[0278] Will refer to Fig.24 Operations to be executed by the CPU 201 of the MFP 101 are described.

[0279] In step S2401 , when activating the function of cooperating with the MFP registration server 105 , the CPU 201 transmits a WebSocket connection request to the MFP registration server 105 .

[0280] In step S2402 , the CPU 201 receives a WebSocket connection response from the MFP login server 105 , and establishes a WebSocket connection with the MFP login server 105 .

[0281] In step S2403 , the CPU 201 displays a login screen, and waits for a login request to be transmitted from the MFP login server 105 .

[0282] In step S2404 , the CPU 201 receives a login request transmitted from the MFP login server 105 .

[0283] In step S2405 , the CPU 201 analyzes the received data.

[0284] In step S2406, when the analysis of the received data has succeeded and the user information (such as user ID, email address, role, authority, etc.) has been acquired, the CPU 201 determines that the analysis has succeeded. When the analysis of the received data has failed and the user information has not been acquired, the CPU 201 determines that the analysis has failed.

[0285] In a case where the analysis has succeeded (YES in step S2406), the process proceeds to step S2407. In step S2407, the CPU 201 performs a login process to allow the user corresponding to the acquired user information to log in to the MFP 101.

[0286] In step S2408, the CPU 201 causes the screen to transition from the login screen to the menu screen, and the process related to the login ends.

[0287] If it is determined in step S2406 that the analysis has failed (NO in step S2406), the process proceeds to step S2409. In step S2409, the CPU 201 displays on the UI that an error has occurred, the process returns to step S2403, and the CPU 201 displays the login screen again.

[0288] <Passkey Registration Sequence>

[0289] Will refer to Fig. 22 , Fig.25 , Fig.26A and Fig.26B Describes the flow of processing related to pass key registration.

[0290] Fig.25 1 is a diagram showing an example of an operation screen and an operation flow of the mobile terminal 102 . Fig.26A and Fig.26B It is a sequence diagram showing the flow of processing related to pass key registration.

[0291] In the present exemplary embodiment, the processing to be executed by the MFP 101 is recorded on the software program of the operation unit login service 301 or the FIDO service 321. The software program is stored in a nonvolatile storage device such as the ROM 202 or the HDD 204, and is loaded onto the RAM 203, and the processing is executed accordingly by the CPU 201.

[0292] The processing to be performed by the mobile terminal 102 is recorded on the software program of the web browser 314 or the authenticator 312. The software program is stored in a nonvolatile storage device such as the ROM 212 or the flash memory device 214, and is loaded onto the RAM 213, and the processing is executed accordingly by the CPU 211.

[0293] The processing to be performed by the MFP login server 105 is recorded on the software program of the FIDO service 321 or the MFP management service 322. The software program is stored in a nonvolatile storage device such as the ROM 1702 or the storage device 1710, and is loaded onto the RAM 1702, and the processing is executed accordingly by the CPU 1701.

[0294] In step S2601 , the operation unit login service 301 detects that the user has pressed the pass key registration button 2205 on the login screen 2201 .

[0295] In step S2602, the operation unit login service 301 displays a QR code on the pass key registration screen 2206. Information related to URL1 is embedded in the QR code.

[0296] Next, in step S2603 , the user activates the camera application 313 from the mobile terminal 102 owned by the user himself / herself, and reads the QR code displayed on the operation panel 205 .

[0297] Next, in step S2604 , the camera application 313 , which has read out the URL1 from the QR code, activates the web browser 314 .

[0298] In step S2605 , the web browser 314 accesses the address of URL1.

[0299] In step S2606, the FIDO service 321 of the MFP login server 105 returns the HTML of the screen 2501 for inputting the user ID. The header of the communication packet in step S2606 includes the session ID to be stored in the cookie of the web browser 314. The session ID is used to confirm that subsequent communications are performed in the same session. In the case of subsequent communications performed in a state where the session ID is not stored in the cookie, it can be determined as unauthorized access that is not performed through the required process, and an error can be transmitted as a response.

[0300] In step S2607, the web browser 314 displays the screen 2501 and prompts the user to input a user ID. The user inputs the user ID and presses the “Next” button.

[0301] If the web browser 314 detects input of a user ID, in step S2608 , the web browser 314 transmits the user ID to the FIDO service 321 .

[0302] In step S2609, the FIDO service 321 checks whether the acquired user ID is registered in the account information 1901. In the case where the user ID is registered, the FIDO service 321 issues a password for identification of the user and transmits the password to an email address stored in association with the acquired user ID. The FIDO service 321 may prompt the user to pre-register the phone number of the mobile terminal 102 and transmit the password in a short message instead of an email. In the case where the user ID is not registered in the account information 1901, the FIDO service 321 transmits an error as a response, which is Fig.26A and Fig.26B Not shown in the figure. The FIDO service 321 may return a message for prompting the user to newly register an account.

[0303] In step S2610, the registered FIDO service 321 that has checked the account information returns the HTML of the screen 2502 for entering a password.

[0304] In step S2611, the web browser 314 displays the screen 2502 and prompts the user to enter a password. The user enters the password obtained via email or short message and presses the "Next" button.

[0305] If the web browser 314 detects the input of a password, in step S2612, the web browser 314 transmits the password to the FIDO service 321.

[0306] In step S2613, the FIDO service 321 checks whether the received password is the same as the password it issued. If the passwords are the same, it can be determined that the owner of the mobile terminal 102 and the owner of the email address or phone number registered in the account information 1901 are the same person. Thus, impersonation by others can be prevented. In the case where the passwords are different, the FIDO service 321 transmits an error as a response, which is not shown in Fig.26A and Fig.26B Not shown in the figure.

[0307] In step S2614, the FIDO service 321 that has confirmed that the passwords are the same transmits the HTML of the passkey registration screen 2503 as a response. The HTML of the screen 2503 covers the JavaScript of the REST APIs for accessing URL2 and URL3. The HTML also covers the following JavaScript of WebAuthn defined by FIDO2.0.

[0308] <JavaScript of WebAuthn>

[0309] Output JSON data = await navigator.credentials.create(Input JSON data);

[0310] In step S2615, the web browser 314 that has received the HTML in step S2614 executes JavaScript and accesses URL2. At this time, it is desired to access URL2 by automatically executing JavaScript without the need for user operations on the web browser. By using the onload event of JavaScript called at the timing when the web browser 314 finishes reading the HTML of the HTML screen 2503, JavaScript can be automatically executed. Alternatively, a "passkey registration" button (not shown) can be displayed on the HTML screen 2503, and JavaScript can be executed when it is detected that the user presses the "passkey registration" button to allow access to URL2.

[0311] In step S2616, the FIDO service 321 that has received the access to URL2 generates a challenge. The challenge corresponds to a random number.

[0312] In step S2617, the input JSON data including the generated challenge is transmitted as a response. The input JSON data also includes information related to the FIDO service 321 (e.g., an address like "mfplogin.service.com") and the user ID.

[0313] Next, in step S2618, the web browser 314 executes the following WebAuthn JavaScript using the received input JSON data and activates the authenticator 312.

[0314] <WebAuthn JavaScript>

[0315] Output JSON data = await navigator.credentials.create(input JSON data);

[0316] Next, in step S2619, the authenticator 312 authenticates the owner of the mobile terminal 102 using any method such as biometric authentication using facial authentication or fingerprint authentication, password-based authentication, and pattern authentication.

[0317] Next, in step S2620, the authenticator 312 generates a key pair (a secret key and a public key of PKI) called a passkey and a credential ID for identifying the passkey. Then, the authenticator 312 stores the generated key and credential ID in a tamper-proof storage area in association with the information related to the FIDO service 321 (e.g., mfplogin.service.com) and the user ID.

[0318] Next, in step S2621, the authenticator 312 uses the generated secret key to give a digital signature to the data including the challenge data received in step S2617. The authenticator 312 returns output JSON data to the web browser. The output JSON data includes the generated public key, the credential ID, and the digital signature.

[0319] Next, in step S2622 , the web browser 314 accesses URL3 and transmits the output JSON data including the public key, credential ID, and digital signature to the FIDO service 321 .

[0320] Next, in step S2623, the FIDO service 321 verifies the received digital signature. Specifically, by using the received public key to decode the digital signature, the FIDO service 321 verifies whether the digital signature is the same as the challenge issued by itself. When the digital signature is the same as the challenge, it is determined that the verification of the digital signature has succeeded. When the digital signature is different from the challenge, it is determined that the verification of the digital signature has failed. When the verification of the digital signature has succeeded, in step S2624, the FIDO service 321 stores the pass key information (public key and credential ID) and the user ID in association with each other in the account information 1901.

[0321] Next, in step S2625, the FIDO service 321 transmits a response indicating whether the pass key registration has succeeded to the web browser 314. In the case where the pass key registration has succeeded, the FIDO service 321 transmits, for example, the HTML of the screen 2505 as a response.

[0322] In the above-mentioned process of pass key registration, an example is described in which the mobile terminal 102 obtains URL1 by reading the QR code displayed on the operation panel 205 of the MFP 101, but the method of notifying the mobile terminal 102 of URL1 may be another method. For example, the MFP 101 may notify the mobile terminal 102 of URL1 using short-range wireless communication such as Bluetooth or near field communication (NFC). Alternatively, the MFP login server 105 may notify the user of URL1 using an e-mail. At the time of pass key registration, the user does not need to be present in front of the MFP 101. In the event that an error occurs in the sequence related to pass key authentication to be described below, it may be determined that access is made from a mobile terminal for which a pass key has not been registered, and the mobile terminal may be prompted to access URL1 for pass key registration.

[0323] <Passkey Authentication Sequence>

[0324] Will refer to Fig. 22 , Fig.25 , Fig.27A and Fig.27B Describes the process flow associated with passkey registration. Fig.27A and Fig.27B It is a sequence diagram showing the flow of processing related to pass key registration.

[0325] In a case where the user has not performed login, then in step S2701, the operation unit login service 301 starts display of the login screen 2201. For example, if the logged-in user performs logout, the operation unit login service 301 displays the login screen 2201. Alternatively, if the power of the MFP 101 is turned on, the operation unit login service 301 displays the login screen 2201 as the initial screen.

[0326] In step S2702, the operation unit login service 301 generates a random number. The random number corresponds to a character string such as "b15dee080a1a549be6e3c74e6b59f5c5", for example.

[0327] Next, in step S2703, the operation unit login service 301 transmits the generated random number to the FIDO service 321 of the MFP login server 105, and shares the random number with the FIDO service 321. The random number may be generated by the FIDO service 321 or another module instead of the operation unit login service 301, and shared with the operation unit login service 301. The FIDO service 321 may generate not only the random number but also the QR code itself and share them with the operation unit login service 301.

[0328] Next, in step S2704, the operation unit login service 301 displays a QR code on the login screen 2201. As URL parameters, data of URL4 including the above-mentioned random number and the MFP-ID of the MFP 101 is embedded in the QR code. The random number corresponds to information known only to a person who has read the QR code image, and is intended to confirm that the user who accesses URL4 is present in front of the operation panel 205.

[0329] Next, in step S2705 , the user activates the camera application 313 from the mobile terminal 102 owned by the user himself / herself, and reads the QR code displayed on the operation panel 205 .

[0330] Next, in step S2706 , the camera application 313 , which has read out the URL 4 from the QR code, activates the web browser 314 .

[0331] Next, in step S2707 , the web browser 314 accesses the address of URL4 .

[0332] In step S2708, the FIDO service 321 of the MFP 101 verifies whether the random number included in the parameters of the URL4 accessed in step S2707 is the same as the random number obtained in step S2703. In the case where the random numbers are different or where no random number is included, an error such as HTTP 1904 Not Found is transmitted as a response to the web browser 314. In the case where it has been confirmed that the random numbers are the same, the MFP-ID included in the parameters of the URL4 is temporarily stored in the RAM 1703 in association with the session ID.

[0333] In step S2709, the HTML of the HTML screen 2510 for passkey authentication is transmitted as a response. The HTML for passkey authentication covers JavaScript for accessing the REST APIs of the URLs 5 and 6. The HTML also covers the following JavaScript of WebAuthn defined by FIDO2.0.

[0334] <JavaScript of WebAuthn>

[0335] Output JSON data = await navigator.credentials.get(Input JSON data);

[0336] The header of the communication packet in step S2709 includes the session ID to be stored in the cookie of the web browser 314. The session ID is used to confirm subsequent accesses within the same session. In the case of accessing the URL5 or URL6 in a state where the session ID is not stored in the cookie, it can be determined as unauthorized access not performed through the required process, and the FIDO service 321 can return an error without performing the requested process.

[0337] In step S2710, it is expected that the web browser 314 that has received the packet in step S2709 accesses the URL5 by automatically executing JavaScript without any web browser operation by the user. The JavaScript can be automatically executed by using the onload event of the JavaScript called at the timing when the reading of the HTML of the HTML screen 2510 is completed in the web browser 314.

[0338] Alternatively, a "Passkey Authentication" button (not shown) can be displayed on the HTML screen 2510, and the JavaScript can be executed when it is detected that the user presses the "Passkey Authentication" button to allow access to the URL5.

[0339] In step S2711, the FIDO service 321 that has received an access to URL5 generates a challenge. The challenge corresponds to a random number.

[0340] Next, in step S2712, the input JSON data including the generated challenge is transmitted as a response. The input JSON data also includes information related to the FIDO service 321 (e.g., an address such as "mfplogin.service.com").

[0341] Next, in step S2713, the web browser 314 executes the following WebAuthn JavaScript using the received input JSON data and activates the authenticator 312. In the case where the authenticator 312 manages multiple passkeys in association with information related to the FIDO service 321, in some cases, a screen for selecting one passkey from multiple passkeys may be displayed.

[0342] <WebAuthn JavaScript>

[0343] Output JSON data = await navigator.credentials.create(input JSON data);

[0344] Next, in step S2714, the authenticator 312 authenticates the owner of the mobile terminal 102 using any method of face authentication, fingerprint authentication, password authentication, and pattern authentication.

[0345] Next, in step S2715, the authenticator 312 obtains the passkey (the secret key of PKI) stored in association with the information related to the FIDO service 321 (e.g., mfplogin.service.com). Then, a digital signature is generated using the secret key for the data including the challenge received in step S2712. The authenticator 312 returns the output JSON data to the web browser 314. The output JSON data includes the digital signature and the credential ID of the passkey used in generating the digital signature.

[0346] Next, in step S2716, the web browser 314 accesses URL6 and transmits the output JSON data including the public key, the credential ID, and the digital signature to the FIDO service 321.

[0347] Next, in step S2717, the FIDO service 321 refers to the account information 1901 and obtains the user ID and the public key of the account associated with the received credential ID.

[0348] Next, in step S2718, the FIDO service 321 verifies the received digital signature. Specifically, by using the public key to decode the digital signature, the FIDO service 321 verifies whether the digital signature is the same as the challenge issued by itself. If the digital signature is the same as the challenge (i.e., the verification of the digital signature has succeeded), it is determined that the authentication has succeeded. If the verification has failed, it is determined that the authentication has failed.

[0349] Next, in step S2719, it is determined whether the user can log in to the MFP 101 having the MFP-ID stored in association with the session ID. Specifically, with reference to table 1903, it is determined whether the user having the user ID that has been successfully authenticated in step S2718 is permitted to use the MFP 101. In addition, with reference to the MFP management information 2001, it is checked whether the MFP 101 is online and whether the MFP 101 is in the ready state. In the case where the user having the user ID is permitted to use the MFP 101 and the MFP 101 is online and in the ready state, it is determined that the user can log in to the MFP 101.

[0350] In step S2720, the FIDO service 321 transmits as a response an HTML including a message indicating the authentication result in step S2718 and the judgment result of the login executable obtained in step S2719. For example, in the case where the authentication has succeeded and it is judged that the login is executable, the FIDO service 321 transmits as a response the HTML of the screen 2512. In the case where the user with the user ID is not permitted to use the MFP 101, the FIDO service 321 transmits as a response the HTML of the screen 2513.

[0351] If the authentication has succeeded and it is determined that login is executable, then in step S2721, the MFP login server 105 transmits user information about the account to be logged into the MFP 101 to the cloud communication unit 308 of the MFP 101. The user information includes information such as the user ID, email address, role, and authority stored in the account information 1901.

[0352] In step S2722, the cloud communication unit 308 of the MFP 101 transmits the received user information to the login processing unit 302, and the login processing unit 302 performs login processing. The login processing unit 302 notifies a login occurrence event to the operation unit UI service 304. The login occurrence event includes information about the user causing the login to be performed.

[0353] If the login process is completed, in step S2723, the login screen 2201 is closed, and the operation unit UI service 304 displays the menu screen 2202. Then, the operation unit UI service 304 provides a function suitable for the authority given to the user. For example, control is performed in such a way that a button of a function for which the authority is not given to the user is displayed in a gray state so that the function cannot be used.

[0354] In the case where the authentication has not succeeded in step S2718, or in the case where it is determined in step S2719 that the login is not executable, the MFP login server 105 transmits a failure notification to the cloud communication unit 308 of the MFP 101. Examples of failure include "user ID is not registered", "public key of the passkey is not registered in association with the user ID", "verification of the digital signature has failed", and "authority to log in to the MFP 101 is not given". It is expected that the operation unit login service 301 displays an authentication failure message as in the screen 2204.

[0355] When receiving the authentication success notification or the authentication failure notification, it is desirable to update the random number to be stored in the QR code on the login screen 2201 to a new random number. It is safe to shorten the life of the random number by regularly updating the random number even if the authentication success notification or the authentication failure notification is not received.

[0356] In the above-mentioned process of pass key authentication, an example is described in which the mobile terminal 102 obtains URL4 and a random number by reading a QR code displayed on the operation panel 205 of the MFP 101, but the method of notifying the mobile terminal 102 of URL4 may be another method. For example, the MFP 101 may notify the mobile terminal 102 of URL4 using short-range wireless communication such as Bluetooth or NFC.

[0357] <Effect>

[0358] As described above, by using the present exemplary embodiment, it is possible to authenticate a user via an external server having a signature verification technology, and provide a system for giving permission to use an operation panel (operation unit) of an image forming apparatus.

[0359] Since the present exemplary embodiment allows the user to log in to the operation panel using the biometric authentication function of the mobile terminal owned by the user, password-less login can be provided without the additional cost of an IC card reading device.

[0360] In conventional technology, there is a possibility that the encrypted password is leaked to the network, and there is also a risk of password leakage due to code cracking. In this exemplary embodiment, the digital signature verification technology used in FIDO is used, so there is less chance that the password is leaked to the network or leaked due to eavesdropping by a third party, thereby providing a secure login method.

[0361] An external server having the signature verification technology can collectively manage multiple users, public keys registered from the users' mobile terminals, and multiple MFPs.

[0362] By registering the public key from the mobile terminal only once on an external server having the signature verification technology, the user becomes able to log in to a plurality of image forming apparatuses, which is convenient for the user.

[0363] An administrator can perform management of users and management of image forming apparatuses on an external server having a signature verification technology, which provides high manageability.

[0364] By using the technology of this exemplary embodiment, the mobile terminal and the image forming device do not need to communicate directly with each other, and pre-configuration or setting and infrastructure (LAN, direct communication) for making the mobile terminal and the image forming device communicate directly with each other are not required. Thus, the burden of pre-configuration or setting can be reduced. This exemplary embodiment can also be applied to an image forming device installed in an office without a LAN or a location where an indefinite number of users such as a convenience store use the image forming device.

[0365] By using the technology of the present exemplary embodiment, the image forming device does not need to have a FIDO client function and does not need to include an authenticator. Thus, there is no need for development costs for implementing the client function and the authenticator on the image forming device. By using a QR code as in the present exemplary embodiment, a short-range wireless communication device compliant with Bluetooth or NFC is not required. By using the technology of the present exemplary embodiment, a relatively inexpensive image forming device capable of providing a secure login method can be provided.

[0366] The mobile terminal has the function of reading the QR code using the camera of the mobile terminal, activating a standard browser, and accessing the URL embedded in the QR code. Thus, there is no need to install a dedicated mobile application, and the function can be used only through a standard camera and a standard browser provided in the mobile terminal.

[0367] In the third exemplary embodiment, an example of using a standard camera and a standard browser provided in a mobile terminal is described.

[0368] As a fourth exemplary embodiment, an MFP application may be used instead of using a standard web browser and camera application of the mobile terminal 102. Specifically, an MFP application installable on the mobile terminal 102 may be provided by a vendor, and the MFP application may be used to log in to the MFP 101.

[0369] The advantage of using the MFP application is that authentication can be performed by accessing the MFP login server 105 faster than in the case of activating a standard camera application and reading a QR code. As another advantage, since the MFP application has the function of generating a key pair and creating a digital signature, even a mobile terminal that does not support a web browser, WebAuthn, or FIDO can use the technology of the present exemplary embodiment. The MFP application does not need to comply with the FIDO standard.

[0370] Fig.28 An example of an operation screen to be displayed on the mobile terminal 102 in the case of using the MFP application is shown.

[0371] If the MFP application is activated, the MFP application communicates with the MFP login server 105, acquires information about the MFP 101 registered on the MFP login server 105, and displays an MFP list on the operation panel 215 of the mobile terminal 102 as in the screen 2801. The MFPs that the user usually uses can be registered in advance as favorite MFPs, and the favorite MFPs can be displayed preferentially.

[0372] If it is detected that the user has selected the MFP, a screen 2802 for inputting a PIN code is displayed. On the MFP login screen, the PIN code is displayed instead of the QR code. The user visually checks the PIN code displayed on the MFP login screen, and inputs the PIN code on the screen 2802. The input PIN code is transmitted to the MFP login server 105, and the MFP login server 105 checks whether the input PIN code is the same as the PIN code displayed on the MFP login screen. Thus, the user's presence in front of the MFP is confirmed.

[0373] Next, the MFP application uses an API provided by the OS of the mobile terminal 102 to activate the biometric authentication function and authenticate the user.

[0374] In the case where the biometric authentication has succeeded, the MFP application gives a digital signature to the challenge obtained from the MFP login server 105 and transmits the digital signature to the MFP login server 105. In the case where the biometric authentication has failed, the MFP application does not transmit the digital signature. With this system, in the case where the MFP application transmits the digital signature, it is ensured that the biometric authentication has been performed in advance on the mobile terminal 102.

[0375] The MFP login server verifies the received digital signature, thereby being able to confirm that the mobile terminal 102 is a legitimate mobile terminal having a secret key that forms a pair with a public key pre-registered by the MFP application of the mobile terminal 102 .

[0376] The above-mentioned PIN code check function can be omitted. In this case, since it cannot be confirmed whether there is a user who performs mobile operation in front of MFP 101, the user is permitted to log in to the operation panel 205 of MFP 101 from a remote location. Since a legitimate user has no advantage in logging in to the operation panel 205 of MFP 101 from a remote location, there is no great security-related concern. Considering the case where a user logs in to MFP 101 by mistake, it is desirable to enable the user to log out from the operation panel 205 of MFP 101 by using a system similar to the system for logging in using an MFP application.

[0377] In the third exemplary embodiment, a description is given of an example in which a user ID is not specifically processed on the login screen of the operation panel (operation unit) of the MFP, and a user to perform passkey registration and passkey authentication is identified through communication between a mobile terminal and an MFP login server.

[0378] In the fifth exemplary embodiment, reference will be made to Fig.29 , Fig. 30A and Fig. 30B An example is described in which communication between a mobile terminal and an MFP login server is started after a user who is to perform pass key registration and pass key authentication is identified on a login screen of an operation panel of an MFP.

[0379] Fig.29 is a diagram showing an example of a user interface to be displayed on an operation panel of an MFP according to a fifth exemplary embodiment.

[0380] Fig. 30A and Fig. 30B is a sequence diagram showing the flow of processing for pass key registration and pass key authentication according to the fifth exemplary embodiment.

[0381] Before displaying the login screen, in step S3001 , the MFP 101 transmits a request for a list of users who can use the MFP 101 to the MFP login server 105 .

[0382] In step S3002, referring to the account information 1901 and the table 1903 indicating associations of users with MFPs that the users can use, the MFP login server 105 transmits as a response a list of users who can use the MFP 101. The user list is expected to include information indicating whether a passkey is registered.

[0383] Next, in step S3003, the MFP 101 displays a login screen 2901. On the login screen 2901, a list of users who can use the MFP 101 is displayed in a button form. "User ID", "display name associated with user ID" and "icon image associated with user ID" may be displayed on each button.

[0384] In step S3004, pressing of any user button representing a user displayed on the login screen 2901 is detected, and the user ID associated with the pressed user button is identified.

[0385] The MFP 101 determines whether the pressed user button is a button indicating a user who has registered a pass key.

[0386] If the pressed user button is a button indicating a user who has not registered a pass key, then in step S3005, a pass key registration screen 2902 is displayed. On the pass key registration screen 2902, a QR code storing the following URL1 including the identified user ID as a URL parameter is displayed.

[0387] https: / / mfplogin.service.com / registration?uid=Alice

[0388] Next, in step S3006 , the user activates the camera application 313 from the mobile terminal 102 owned by the user himself / herself, and reads the QR code displayed on the operation panel 205 .

[0389] Next, in step S3007 , the camera application 313 , which has read out the URL1 from the QR code, activates the web browser 314 .

[0390] In step S3008, the web browser 314 accesses the address of URL 1. Unlike the first exemplary embodiment, the URL parameter when URL 1 is accessed for the first time includes the user ID read out from the QR code.

[0391] In step S3009, the MFP login server 105 transmits the password to the email address stored in association with the acquired user ID. The MFP login server 105 may prompt the user to pre-register the phone number of the mobile terminal 102 and transmit the password in a short message instead of an email.

[0392] In step S3010 , the FIDO service 321 returns the HTML of the screen 2502 for inputting a password together with the issued session ID.

[0393] The subsequent processing is similar to the processing in steps S2611 to S2625 described in the third exemplary embodiment.

[0394] If the button pressed in step S3004 is a button indicating a user who has registered a pass key, then in step S3011 , the MFP 101 transmits the identified user ID to the MFP login server 105 .

[0395] In step S3012 , the MFP login server 105 temporarily stores the received user ID in the RAM 1703 .

[0396] In step S3013, the MFP 101 displays a pass-key authentication screen 2903 on the operation panel 205. On the pass-key authentication screen 2903, a QR code storing the following URL4 including the recognized user ID and MFP-ID as URL parameters is displayed.

[0397] https: / / mfplogin.service.com / authentication?uid=Alice&MFP-ID=theMFP 101

[0398] Next, in step S3014 , the user activates the camera application 313 from the mobile terminal 102 owned by the user himself / herself, and reads the QR code displayed on the operation panel 205 .

[0399] Next, in step S3015 , the camera application 313 , which has read out the URL 4 from the QR code, activates the web browser 314 .

[0400] In step S3016, the web browser 314 accesses the address of URL 4. Unlike the first exemplary embodiment, the URL parameter when URL 4 is accessed for the first time includes the user ID read out from the QR code.

[0401] In step S3017, the FIDO service 321 of the MFP 101 verifies whether the user ID included in the parameter of the URL4 accessed in step S2707 is the same as the user ID temporarily stored in step S3012. If the user ID is not the same, or if the user ID is not included, an error is transmitted to the web browser 314 as a response.

[0402] When it is confirmed that the user IDs are identical, the MFP-ID included in the parameter of the URL4 is temporarily stored in the RAM 1703 in association with the session ID.

[0403] In step S3018, the HTML of the HTML screen 2510 for passkey authentication is transmitted as a response. The HTML for passkey authentication includes JavaScript for accessing the REST API of URL5 and URL6. The HTML also includes JavaScript for WebAuthn defined by FIDO2.0.

[0404] The header of the communication packet in step S3018 includes a session ID to be stored in the Cookie of the web browser 314. The session ID is used to confirm that subsequent accesses are made in the same session.

[0405] In step S3019, the web browser 314 that has received the packet in step S3018 accesses URL5 by executing JavaScript.

[0406] In step S3020, the FIDO service 321 that has received the access to URL 5 generates a challenge. The challenge corresponds to a random number.

[0407] Next, in step S3021, the input JSON data including the generated challenge is transmitted as a response. The input JSON data also includes information related to the FIDO service 321 (e.g., an address like "mfplogin.service.com"). The input JSON data also includes the credential ID associated with the user ID temporarily stored in step S3012.

[0408] Next, in step S3022, the web browser 314 executes the following JavaScript of WebAuthn using the received input JSON data and activates the authenticator 312. The authenticator 312 generates a digital signature using a secret key corresponding to the credential ID included in the input JSON data. In the absence of a secret key corresponding to the credential ID, an error is transmitted as a response.

[0409] The subsequent processing is similar to the processing in steps S2714 to S2723 described in the third exemplary embodiment. However, in step S3012, control is performed so as not to accept authentication of a user ID other than the temporarily stored user ID.

[0410] In the process of acquiring the public key in step S2717, if the credential ID included in the output JSON data transmitted in step S2716 is not the credential ID corresponding to the temporarily stored user ID, the acquisition of the public key is not performed and an error is transmitted as a response. In other words, control is performed so as not to accept authentication of users other than the user associated with the button pressed in step S3004.

[0411] When a cancel button is pressed on the passkey authentication screen 2903 or when a timeout occurs, it is desirable that the MFP 101 returns the screen on the operation panel to the login screen 2901 and notifies the MFP login server 105 of the cancellation.

[0412] With the above configuration, since a pass key can be registered by selecting a user on the operation panel of the MFP, the user does not feel troublesome to input a user ID, which enhances usability.

[0413] Since only the user who has selected the user on the operation panel of the MFP can log in to the operation panel of the MFP through the passkey authentication, unauthorized login requests to the operation panel of the MFP from a remote location can be prevented, so that a secure login method can be provided.

[0414] In the case of using the MFP application of the mobile terminal described in the fourth exemplary embodiment in combination, it is not necessary to always perform QR code reading. On the operation panel of the MFP, after selecting a user by pressing a button representing the user, the MFP to be logged in by the user is selected from the MFP application of the mobile terminal, and the pass key authentication can be started. If it is confirmed that the credential ID of the pass key of the user selected on the operation panel of the MFP is the same as the credential ID of the pass key used when generating a digital signature on the mobile terminal, the user can be permitted to log in to the operation panel of the MFP.

[0415] <Other Exemplary Embodiments>

[0416] The operation unit login service 301 of the MFP 101 may include WebView (a UI component having a web browser function). Then, a login screen created based on HTML acquired from the MFP login server 105 through HTTPS communication with the MFP login server 105 may be displayed as a login screen of the operation panel 205 of the MFP 101. In this case, the MFP login server 105 provides HTML of a screen equivalent to the login screen 2201, the pass key registration screen 2206, the login screen 2901, the pass key registration screen 2902, or the pass key authentication screen 2903. The MFP login server 105 can thereby detect the operation unit status and user operation of each MFP in real time.

[0417] The present invention can also be implemented by supplying a program for implementing one or more functions of the above exemplary embodiments to a system or device via a network or storage medium, and causing one or more processors in a computer of the system or device to read and execute the program. The present invention can also be implemented by a circuit (e.g., an application specific integrated circuit (ASIC) or a field programmable gate array (FPGA)) that implements one or more functions.

[0418] According to an image forming apparatus according to an exemplary embodiment of the present invention, a system for verifying data signed on a terminal on the image forming apparatus can be provided.

[0419] Other embodiments

[0420] The embodiments of the present invention may also be implemented by providing software (program) for performing the functions of the above-described embodiments to a system or device via a network or various storage media, and a computer or a central processing unit (CPU) or a microprocessing unit (MPU) of the system or device reads and executes the program.

[0421] While the present invention has been described with reference to exemplary embodiments, it is to be understood that the invention is not limited to the disclosed exemplary embodiments.The scope of the following claims is to be accorded the broadest interpretation so as to encompass all such modifications and equivalent structures and functions.

Claims

1. An image forming device configured to communicate with a terminal having an authentication function, the image forming device comprising: at least one memory storing at least one program; as well as at least one processor, wherein the at least one processor reads the at least one program from the at least one memory and executes the at least one program to cause the image forming device to: transmitting verification data for performing user authentication of the image forming device to the terminal, receiving signature data from the terminal, the signature data being obtained by encrypting the verification data using a secret key corresponding to the authentication based on execution of the authentication in the authentication function of the terminal, and using the verification data and a public key corresponding to the secret key to verify the received signature data, Wherein, when the verification is successful, a function based on the user authentication is provided.

2. The image forming apparatus according to claim 1, in, The image forming device is an image forming device including a printer, and Wherein, in a case where the verification has succeeded, a printing function to be executed by the printer with predetermined print settings is provided as a function premised on the user authentication.

3. The image forming apparatus according to claim 1, in, The image forming device is an image forming device including a scanner, and Here, when the verification has succeeded, a function of transmitting image data obtained by scanning performed by the scanner to an external device is provided as a function premised on the user authentication.

4. The image forming apparatus according to claim 3, in, In a case where the verification has succeeded, a function of selecting and specifying a transmission destination from an address book when specifying a transmission destination of image data obtained by scanning performed by the scanner is provided as a function premised on the user authentication.

5. The image forming apparatus according to claim 1, in, The image forming device is an image forming device including a printer and a scanner, and Among them, when the verification has succeeded, a function of performing settings related to printing to be performed using the printer and scanning to be performed using the scanner is provided as a function premised on the user authentication.

6. The image forming apparatus according to claim 1, in, registering the public key corresponding to the secret key on the image forming apparatus, and The verification is performed using the registered public key.

7. The image forming apparatus according to claim 6, in, The at least one processor further causes the image forming device to: transmitting verification data for registration of the public key to the terminal; and receiving, from the terminal, the public key corresponding to the secret key that has been generated based on execution of authentication in an authentication function of the terminal, and signature data for registration obtained by encrypting verification data for registration using the secret key, Wherein, in a case where verification of the signature data for registration using the verification data for registration and the received public key has succeeded, the received public key is registered on the image forming apparatus.

8. The image forming apparatus according to claim 6, in, The public key is registered in association with user information about a user who uses the image forming apparatus.

9. The image forming apparatus according to claim 1, in, The at least one processor further causes the image forming device to: displaying a quick response code (QR code) on an operation panel of the image forming device, the QR code including information related to a uniform resource locator (URL) for accessing the image forming device; as well as When access to the URL from the terminal is detected, the authentication data is transmitted to the terminal.

10. The image forming apparatus according to claim 1, wherein: The at least one processor further causes the image forming apparatus to receive a user operation of selecting a method for performing the user authentication from options including a method using the public key and a method using a password input by a user.

11. The image forming apparatus according to claim 1, wherein: The authentication function of the terminal is a function of authenticating biometric information.

12. The image forming apparatus according to claim 1, in, The at least one processor further causes the image forming device to: receiving a selection of an icon representing a user; and The authentication is performed using the authentication data and a public key that is a public key corresponding to the secret key and is managed in association with the user represented by the selected icon.

13. The image forming apparatus according to claim 12, in, The at least one processor further causes the image forming device to: managing information indicating whether to perform the authentication in association with the user; and When the icon representing the user associated with the information indicating whether to perform the authentication is selected, a screen for transmitting the authentication data to the terminal is displayed.

14. A control method for an image forming device, the image forming device being configured to communicate with a terminal having an authentication function, the control method comprising: transmitting, to the terminal, verification data for performing user authentication of the image forming device; receiving signature data from the terminal, the signature data being obtained by encrypting the verification data using a secret key corresponding to the authentication based on execution of authentication in an authentication function of the terminal; as well as using the verification data and a public key corresponding to the secret key to verify the received signature data, Wherein, when the verification is successful, a function based on the user authentication is provided.

15. A computer-readable storage medium storing a computer program for executing a control method of an image forming device, the image forming device being configured to communicate with a terminal having an authentication function, the control method comprising: transmitting, to the terminal, verification data for performing user authentication of the image forming device; receiving signature data from the terminal, the signature data being obtained by encrypting the verification data using a secret key corresponding to the authentication based on execution of authentication in an authentication function of the terminal; as well as using the verification data and a public key corresponding to the secret key to verify the received signature data, Wherein, when the verification is successful, a function based on the user authentication is provided.

16. A server configured to communicate with an image forming device and a terminal, the server comprising: at least one memory storing at least one program; as well as at least one processor, The at least one processor reads the at least one program from the at least one memory and executes the at least one program to enable the server to: receiving identification information related to the image forming device from the terminal; receiving signature data from the terminal and performing verification of the signature data, the signature data being obtained by encrypting verification data used for performing user authentication of the image forming apparatus; as well as transmitting, based on success of the verification, to the image forming apparatus identified based on the identification information, an instruction to execute a login process of the user authenticated by the user authentication, Here, a login process of the user is executed on the image forming device according to the instruction.

17. The server according to claim 16, in, The image forming device is an image forming device including a printer, and Here, when the login process is executed, printing with predetermined print settings becomes executable by the printer.

18. The server according to claim 16, in, The image forming device is an image forming device including a scanner, and When the login process is executed, the image data obtained by scanning performed by the scanner can be transmitted to an external device.

19. The server according to claim 16, in, The at least one processor further causes the server to: managing identification information related to the user and the public key acquired from the terminal in association with each other; and The signature data is verified using the public key.

20. The server according to claim 16, in, The at least one processor further causes the server to: managing identification information about the user and identification information about an image forming device that the user can use in association with each other; and The instruction is transmitted to the image forming apparatus identified based on the received identification information and associated with the identification information related to the user authenticated by the user authentication.

21. The server according to claim 16, in, The signature data is obtained by encrypting the verification data using a secret key through execution of authentication based on a function of authenticating biometric information in the terminal.

22. A method for controlling a server, the server being configured to communicate with an image forming device and a terminal, the method comprising: receiving identification information related to the image forming device from the terminal; receiving signature data from the terminal and performing verification of the signature data, the signature data being obtained by encrypting verification data used for performing user authentication of the image forming apparatus; as well as transmitting, based on success of the verification, to the image forming apparatus identified based on the identification information, an instruction to execute a login process of the user authenticated by the user authentication, Here, a login process of the user is executed on the image forming device according to the instruction.

23. A computer-readable storage medium storing a computer program for executing a control method of a server configured to communicate with an image forming device and a terminal, the control method comprising: receiving identification information related to the image forming device from the terminal; receiving signature data from the terminal and performing verification of the signature data, the signature data being obtained by encrypting verification data used for performing user authentication of the image forming apparatus; as well as transmitting, based on success of the verification, to the image forming apparatus identified based on the identification information, an instruction to execute a login process of the user authenticated by the user authentication, Here, a login process of the user is executed on the image forming device according to the instruction.

Images