JP4727263B2 - Image processing apparatus, user authentication method, and user authentication program - Google Patents

Description

The present invention relates to an image processing apparatus, a user authentication method, and a user authentication program, and in particular, authenticates a user and proves whether the authenticated user is executable when executing a function. It relates to the technology to be performed.

  2. Description of the Related Art Conventionally, there has been known a multi-function machine in which a plurality of functions such as a printer, a copy, and a scanner are stored in a single casing. In such a multifunction device, a plurality of applications called a printer application, a copy application, and a scanner application are mounted on a general-purpose OS such as UNIX (R), and a plurality of functions are realized while switching execution processes of these applications. .

  However, since the printer application, the copy application, and the scanner application perform engine control, memory control, system control, and the like separately, wasteful duplication processing has occurred.

  For this reason, in Patent Document 1, the applications such as engine control, memory control, and system control, which have been performed by a plurality of applications installed in the multifunction peripheral, are grouped from each application as a common processing part (platform). The development efficiency is improved.

  Further, in Patent Document 2, print control software installed in a printing apparatus is composed of a plurality of software components based on object-oriented design, and printing processing is performed by cooperative operation of such component groups.

JP 2002-084383 A Japanese Patent Laid-Open No. 11-327883

  However, the invention disclosed in Patent Document 1 shares the processing part that controls the hardware, and does not share the overall internal processing of each application. Since internal processing is not divided into classes according to functions, there is a problem that the development efficiency of internal processing in general is not good. In other words, in order to improve development efficiency, applications on the multifunction peripheral have room for improvement by sharing the internal processing and dividing the characteristic functions into classes.

  For example, when a user performs authentication when using a function provided in the device, the authentication for each function is made common and authentication is performed using the managed user information. It is possible to divide the function that proves that the user can use the function.

  The invention disclosed in Patent Document 2 is a print control software configured by a plurality of software components based on object-oriented design, and authentication of a user who uses the function or an authenticated user uses the function. It does not disclose software components that control the flow until it can be proved. Therefore, in a multi-function machine that determines whether or not a user has the authority to be executed for each function by multi-functionalization, a software component corresponding to user authentication by applying the invention disclosed in Patent Document 2 Even if a user is created, the function to authenticate using the managed user information and the function to prove that the authenticated user can use the function are divided into user authentication processing and authentication. It is not easy to efficiently control the process of proving that the authorized user can use the function.

  For these reasons, it is a big issue how to efficiently realize the authentication process of the user of the application installed in the MFP and whether the authenticated user can use the function or not. . Note that such a problem does not arise only for the multifunction peripheral. For example, when a user who has a plurality of functions and has a predetermined authority performs authentication, a user authentication device that permits execution for each function This is also a problem that arises in the same way when forming.

The present invention has been made to solve the above-described problems caused by the prior art, and can efficiently control user authentication processing and proof processing that an authenticated user can use the function. It is an object to provide a processing device, a user authentication method, and a user authentication program.

In order to solve the above-described problems and achieve the object, the invention according to claim 1 is an image processing apparatus in which a plurality of applications cooperate to execute image processing, and a user who can use the apparatus is selected. User management means for managing user information to be displayed, receiving an authentication request as to whether or not the user is the usable user from an input means, and authenticating the user based on the user information; , authentication before SL user a license to be a proof of the authenticated user in the user management unit, issuing a permit which is associated with the input means performing the authentication request Whether the certification means and user function correspondence information indicating a user who can be executed for each application are managed, and the user to whom the permit is issued can execute a predetermined application linked in execution of image processing or not Receiving a confirmation request from the license, and a function limiting means for the user to confirm whether it can execute the predetermined application based on the user function correspondence information, the permit, The function to receive a confirmation request from the input means associated with the permit whether or not the user to whom the permit has been issued can execute a predetermined application linked with execution of image processing Output to limiting means,
The authentication certification unit outputs a determination result as to whether or not the user can execute the predetermined application based on the confirmation result of the function restriction unit to the predetermined application .

The invention according to claim 2 is the invention according to claim 1, wherein the user managing means, said input means or et Editing prior SL user information, or the user's the available interest and whether the authentication list means for receiving an authentication request or is to manage the user information, the user information of the edit, or registered to authenticate the user based on the user information And user means.

Further, according invention in claim 3, in the invention according to claim 2, wherein the user managing means manages the user secret information indicating the secret information of the user, using the pre-SL user secret information processing A secret information means for performing processing using the user secret information when the user management information is received , and the authentication list means provided in the user management means uses the user secret information from the input means. It is characterized in that it accepts a processing request .

The invention according to claim 4, managed by the invention according to claim 2 or 3, wherein the registered user means the the user management unit with the use state information indicating the use state prior SL user information The usage state information is changed according to the received processing request .

The invention according to a fifth aspect is the invention according to any one of the first to fourth aspects, wherein the function limiting means manages authority function correspondence information indicating a user authority executable for each application. And receiving a confirmation request as to whether or not the user certified by the authentication certification means is a user who can execute a predetermined application linked to execute image processing , and based on the authority function correspondence information It is characterized by comprising authority management means for confirming that the user can execute the predetermined application .

Further, the invention according to claim 6 is the invention according to any one of claims 2 to 4, wherein the function restricting means includes a permit issued by the authentication certification means from the authentication certification means via the registered user means. The user who issued the information receives a confirmation request as to whether or not the user who can execute the predetermined application linked to execute the predetermined image processing is received, and the authentication certification unit receives the request from the function limiting unit. The confirmation result of the function restriction means is received via the registered user means.

The invention according to claim 7 is the invention according to any one of claims 1 to 6, wherein the function restricting means is configured such that permit information is issued directly by the authentication certification means from the authentication certification means. Accepting a confirmation request as to whether or not the user is a user who can execute a predetermined application that cooperates to execute predetermined image processing, and the authentication certification means directly from the function restriction means The confirmation result by the function restriction means is received.

The invention according to claim 8 is the invention according to any one of claims 1 to 7 , wherein the user management means is a user who can use the same user from a plurality of input means. An authentication request for accepting whether or not there is, and authenticating the same user for each of the plurality of input means based on the user information, wherein the same user manages the user by the same user Permit information for certifying that the user is authenticated by the means is issued for each input means.

The invention according to claim 9 is the invention according to claim 8, wherein the authentication credential means, and issues the authorization number that different for each of the input means.

The invention according to claim 10 is a user authentication method executed by an image processing apparatus in which a plurality of applications cooperate to execute image processing , wherein the user management means can use the own apparatus. User management that manages user information indicating a user, receives an authentication request as to whether or not the user is the usable user from an input means, and authenticates the user based on the user information a step, authentication credentials means, even before Symbol permit the user is proof of the user authenticated by the user management step, in association with the input means performing the authentication request an authentication certificate issuing a permit to have the function limiting means, to manage the user function correspondence information indicating the user executable for each of the application, the user that license is issued to execute the image processing so A predetermined whether the confirmation request whether the application is capable of executing the mobile received from the license, the user based on the user function corresponding information to check whether it can execute the predetermined application In the function restriction step, and in the function restriction step, the permit makes a confirmation request as to whether or not the user to whom the permit is issued can execute a predetermined application that cooperates in the execution of image processing. the, the permit steps to be outputted to the function restriction means received from said input means associated with該許friendly card, said authentication proof means, the usage on the basis of the check result of the previous SL function restriction step upon who can and an output step of outputting a determination result whether it is capable of executing the predetermined application to the predetermined application And features.

The invention according to claim 11 is the invention according to claim 10, in the user management step, the authentication list means, editing of the input means or found before SL user information, or user the an authentication list step of receiving the whether's available interest authentication request registered user means to manage the user information, the user information of the editing, or to the user information And a registered user step for performing authentication of the user based on the above .

The invention according to claim 12 is the invention according to claim 11, wherein the user management step manages the user secret information indicating the secret information of the user, using the pre-SL user secret information processing If the accepted, the secret information step of performing processing using the user secret information, further comprising the authentication list step of the user management step had the said user secret information from said input means The processing request used is received.

The invention according to claim 13, managed by the invention according to claim 11 or 12, wherein the registered user step the user management step had the use state information indicating the use state prior SL user information The usage state information is changed according to the received processing request .

The invention according to claim 14 is the invention according to any one of claims 10 to 13, wherein the function restriction step manages authority function correspondence information indicating a user authority executable for each application. And receiving a confirmation request as to whether or not the user certified by the authentication certification means is a user who can execute a predetermined application linked to execute image processing , and based on the authority function correspondence information And an authority management step of confirming that the user can execute the predetermined application .

The invention according to claim 15 is the invention according to any one of claims 11 to 13, wherein the function restricting step is performed by the authentication certification means via the registered user means from the authentication certification means. A request for confirming whether or not the user whose information has been issued is a user who can execute a predetermined application linked to execute image processing is received, and the authentication certification step receives the registration from the function restriction unit The confirmation result of the function restriction means is received via the user means.

According to a sixteenth aspect of the present invention, in the invention according to the fifteenth aspect , in the user management step, an authentication request as to whether or not the same user is the usable user from a plurality of input means. And the authentication of the same user is performed for each of the plurality of input means based on the user information, and the authentication certification step includes the user who is authenticated by the user management step. Permit information is issued for each of the input means to prove that

The invention according to claim 17 is characterized in that the user authentication method according to any one of claims 10 to 16 is executed by an image processing apparatus.

According to the invention according to claim 1, in order to confirm whether or not the user can use the application with the license information generated upon authentication, the proof that the user has been authenticated with the license information and the application Since it is collectively managed whether or not it can be used, it is possible to efficiently control the authentication process of the user and the proof process that the authenticated user can use the application .

  According to the invention of claim 2, the user management means is divided into two parts: an authentication name list means for accepting authentication, and a registered user means for storing user information and authentication information for authentication. Therefore, there is an effect that it is possible to perform function addition and refurbishment more easily.

  According to the invention of claim 3, the secret information of the user is managed by the secret information means, and the secret information means is stored only when the process using the user secret information is accepted in the secret information step. Since it is developed on the area, it is possible to prevent leakage of secret information.

Further, according to the invention according to claim 4, it is possible to prevent authentication during editing of user information or authentication information, for example, by changing the usage state information in response to the processing request received by the authentication list means And has the effect of improving reliability.

Further, according to the invention of claim 5, there is an effect that it is possible to efficiently control the authentication process of the user and the proof process that the authenticated user can use the application .

In addition, according to the invention of claim 6, there is an effect that it is possible to efficiently control the authentication process of the user and the proof process that the authenticated user can use the application .

According to the invention of claim 7, in order to determine whether or not the user can use the application based on the confirmation result from the function restriction means, the user authentication process and the authenticated user There is an effect that it is possible to efficiently control the proof processing that the application can be used.

According to the eighth aspect of the present invention, when the same user is authenticated by a plurality of input means, the permit information is generated for each input means, so that the application is executed for each input means. There is an effect that can be.

According to the ninth aspect of the invention, even when a plurality of authentications are performed, the correspondence relationship with the permit information is clarified, and there is an effect that authentication management is easy.

According to the invention of claim 10, since it is possible to collectively process the proof that the user is authenticated by the permit information and whether or not the application can be used, the user authentication process and There is an effect that it is possible to efficiently control the proof processing that the authenticated user can use the application .

According to the invention of claim 11 , the user management step is divided into an authentication name list step for accepting authentication and a registered user step for storing user information and authentication information for authentication. Since the processing procedure is adopted, there is an effect that the function addition and the modification can be performed more easily.

According to the invention of claim 12 , since the process using the user secret information is performed when the process using the user secret information is accepted in the secret information step, the process is performed when necessary for this process. As long as the secret information is expanded in the storage area, there is an effect that the leakage of the secret information can be prevented.

Further, according to the invention according to claim 13, by changing in response to the processing request accepted by the state information authentication list step using, for example, user information or authentication information allows to prevent authentication during editing And has the effect of improving reliability.

According to the fourteenth aspect of the invention, it is possible to efficiently control the user authentication process and the proof process that the authenticated user can use the application .

In addition, according to the fifteenth aspect of the present invention, it is possible to efficiently control the user authentication process and the proof process that the authenticated user can use the application .

According to the invention of claim 16, when the same user is authenticated by a plurality of input means, the permit information is generated for each input means, so that the application is executed for each input means. There is an effect that can be.

According to the seventeenth aspect of the present invention, the user authentication method according to any one of the tenth to sixteenth aspects is realized by using the image processing apparatus by causing the computer to read and execute the method. The same effects as those of the user authentication methods can be obtained.

Exemplary embodiments of an image processing apparatus, a user authentication method, and a user authentication program according to the present invention are explained in detail below with reference to the accompanying drawings. In the present embodiment, the case where the present invention is applied to an image processing apparatus will be described. However, the present invention is not limited to this, and can be applied to various apparatuses that perform user authentication processing.

(First embodiment)
First, an outline of an image forming apparatus (hereinafter referred to as “multifunction machine”) 1 according to a first embodiment of the present invention will be described with reference to FIGS. 1, 2, 3, 4, 20, and 21. To do. FIG. 1 is a network diagram for explaining a network environment surrounding the MFP 1 according to the present embodiment, and FIG. 2 is a block diagram showing a hardware configuration of the MFP 1 shown in FIG. FIG. 3 is a conceptual diagram for explaining the relationship between software and hardware of the multi-function device 1 shown in FIG. FIG. 4 is a diagram illustrating an example of the operation panel 400 of the multifunction machine 1. FIG. 20 is an explanatory diagram for explaining the transition of the software configuration installed in the multifunction peripheral, and FIG. 21 is an explanatory diagram for explaining the relationship between the software and hardware of the conventional multifunction peripheral. .

  As shown in FIG. 1, devices such as a PC (Personal Computer) provided in an office or the like are connected to a network such as a LAN (Local Area Network) and can communicate with each other due to recent progress in networking. It became normal. For example, as shown in the figure, a client PC, an SMTP (Simple Mail Transfer Protocol) server, an FTP (File Transfer Protocol) server, a server PC, etc. are connected to such a network to send and receive e-mails and transfer files. The modem-connected delivery server can communicate with a fax machine outside the office.

  With the progress of such networking, the multifunction device 1 is also connected to such a network and can communicate with a device such as a PC. By incorporating a storage device such as a hard disk, a so-called network multifunction device can be obtained. It has evolved to meet various user needs.

  Specifically, in addition to the normal copy function, the multi function device 1 is connected to the server PC by a printer function for printing document data and the like by a print request from the client PC, and by a fax request from the client PC. A fax function for transmitting to a fax machine in another office via a modem, and a storage function for storing a received fax document or a copy document in a built-in hard disk. In order to realize such many functions, the software installed in the conventional multi-function machine becomes large and complicated. Along with this, the man-hours for developing and maintaining such software have increased significantly. Therefore, the software installed in the multifunction machine 1 according to the present embodiment reduces the man-hours for development and maintenance. The configuration of software installed in the multifunction machine 1 will be described later.

  FIG. 2 is a block diagram illustrating a hardware configuration of the multifunction machine 1. As shown in the figure, the multi-function device 1 has a configuration in which a controller 10 and an engine unit (Engine) 60 are connected by a PCI (Peripheral Component Interconnect) bus. The controller 10 is a controller that controls the entire multifunction device 1 and controls drawing, communication, and input from an operation unit (not shown). The engine unit 60 is a printer engine that can be connected to a PCI bus, and is, for example, a monochrome plotter, a one-drum color plotter, a four-drum color plotter, a scanner, or a fax unit. The engine unit 60 includes an image processing part such as error diffusion and gamma conversion in addition to a so-called engine part such as a plotter.

  The controller 10 includes a CPU 11, a north bridge (NB) 13, a system memory (MEM-P) 12, a south bridge (SB) 14, a local memory (MEM-C) 17, and an ASIC (Application Specific Integrated Circuit). 16 and a hard disk drive (HDD) 18, and the north bridge (NB) 13 and the ASIC 16 are connected by an AGP (Accelerated Graphics Port) bus 15. The MEM-P 12 further includes a ROM (Read Only Memory) 12a and a RAM (Random Access Memory) 12b.

  The CPU 11 performs overall control of the multifunction machine 1 and includes a chip set including the NB 13, the MEM-P 12, and the SB 14, and is connected to other devices via the chip set.

  The NB 13 is a bridge for connecting the CPU 11 to the MEM-P 12, SB 14, and AGP 15, and includes a memory controller that controls reading and writing to the MEM-P 12, a PCI master, and an AGP target.

  The MEM-P 12 is a system memory used as a memory for storing programs and data, a memory for developing programs and data, a memory for drawing a printer, and the like, and includes a ROM 12a and a RAM 12b. The ROM 12a is a read-only memory used as a program / data storage memory, and the RAM 12b is a writable / readable memory used as a program / data development memory, a printer drawing memory, or the like.

  The SB 14 is a bridge for connecting the NB 13 to a PCI device and peripheral devices. The SB 14 is connected to the NB 13 via a PCI bus, and a network interface (I / F) unit and the like are also connected to the PCI bus.

  The ASIC 16 is an IC (Integrated Circuit) for image processing applications having hardware elements for image processing, and has a role of a bridge for connecting the AGP 15, PCI bus, HDD 18 and MEM-C 17. The ASIC 16 includes a PCI target and an AGP master, an arbiter (ARB) that is the core of the ASIC 16, a memory controller that controls the MEM-C 17, and a plurality of DMACs (Direct Memory) that perform rotation of image data by hardware logic. Access Controller) and a PCI unit that performs data transfer between the engine unit 60 via the PCI bus. An FCU (Fax Control Unit) 30, a USB (Universal Serial Bus) 40, and an IEEE 1394 (the Institute of Electrical and Electronics Engineers 1394) interface 50 are connected to the ASIC 16 via a PCI bus.

  The MEM-C 17 is a local memory used as an image buffer for copying and a code buffer, and an HDD (Hard Disk Drive) 18 is a storage for storing image data, programs, font data, and forms. It is.

  The AGP 15 is a bus interface for a graphics accelerator card proposed for speeding up graphics processing. The AGP 15 speeds up the graphics accelerator card by directly accessing the MEM-P 12 with high throughput. .

  FIG. 3 is a conceptual diagram showing the hardware and software configuration of the multifunction device 1, and specifically, an integrated application 110 including an authentication management unit 211, which is a characteristic part of the present embodiment to be described later, A hierarchical relationship between the software 100 and the hardware 150 is shown. As shown in the figure, the hardware 150 includes a hardware resource 151, and the hardware resource 151 includes a scanner 151a, a plotter 151b, an HDD (Hard Disk Drive) 151c, a network 151d, and other resources 151e. . The other resources 151e are hardware resources 151 other than 151a to 151d, and indicate input / output devices such as an operation panel, for example.

  FIG. 4 is a diagram illustrating an example of the operation panel 400 of the multifunction machine 1. As shown in the figure, the operation panel 400 includes an initial setting key 401, a copy key 402, a copy server key 403, a printer key 404, a transmission key 405, a ten key 406, a clear / stop key 407, a start key 408, a preheat. A key 409, a reset key 410, and a liquid crystal touch panel 420 are provided. When the user performs a predetermined operation on the operation panel 400 having such a configuration, an object that materializes each class, which is a feature of the present embodiment, included in the integrated application 110 operates.

  For example, when the initial setting key 401 is touched, a menu for initial setting is displayed on the liquid crystal touch panel 420, and in this menu, a paper size to be stored and the like can be set. Further, when the user wants to make a copy, the copy key 402 is stored. When the copy result is stored in the multifunction device 1, the copy server key 403 is displayed. When the operation related to the printer is performed, the printer key 404 is displayed. When the user wants to transmit an image or the like, touch the transmission key 405 to display a menu corresponding to the liquid crystal touch panel 420.

  Returning to FIG. 3, the software 100 mounted on the hardware 150 is hierarchized, and a service layer 102 is constructed above the operating system 103, and an application layer 101 is constructed above the service layer 102. ing. The service layer 102 corresponds to a driver that controls each hardware resource (151a to 151e). The scanner control unit 102a, the plotter control unit 102b, the accumulation control unit 102c, the distribution / mail transmission / reception control unit 102d, and the FAX transmission / reception control. Unit 102e, network communication control unit 102f, and other control unit 102g.

  Here, how the software 100 shown in FIG. 3 has reached such a hierarchical structure will be described with reference to FIGS. 20 and 21. FIG. FIG. 20 is an explanatory diagram showing changes in the software configuration installed in the multifunction peripheral. As shown in the pre-service layer separation application 2001 in FIG. 20, the software installed in the multifunctional multifunction peripheral is created as an independent application for each function such as a copy application, a FAX application, and a scanner application, and is shown in FIG. Operating on the operating system 103.

  However, since these applications include a driver (service layer 102) that controls hardware resources, duplicate processing exists in each application. As a result, the scale of each application has become large.

  Therefore, as shown in an application 2002 after service layer separation in FIG. 20, a portion corresponding to the service layer of the application 2001 before service layer separation is bundled into the service layer 102, and each application is an upper layer of the service layer 102. The application layer 101 is constructed. By adopting such a hierarchical structure, each application has been streamlined and development effort has been reduced.

  However, as the networking and multifunctional functions of multi-function peripherals have further progressed, it has become a problem that a common processing part exists in each application. Specifically, each application of the application layer 101, for example, a copy application or a scanner application, performs processing for communicating with a driver such as the scanner control unit 102a or the accumulation control unit 102c, and the flow of data handled by various functions. Similar processing such as stream control to be controlled was included inside. As described above, when each application has the same processing, the development scale of each application is increased, and the improvement scale of each application with respect to the specification change of the service layer is increased.

  In order to solve this problem, as shown in the common routine separation application 2003 in FIG. 21, it has been considered that such a similar process (common processing part) is bundled as a common routine. However, since such a common routine is intended to share slightly different processing in each application, the processing inside the common routine becomes complicated. For example, when adding a new application such as a printer application, it is necessary to modify the common routine in order to adapt to the new application.

  However, since the internal processing of the common routine is complicated, it became difficult for repair personnel to grasp the processing, and there were concerns about the increase in the scale of repair and the impact on other applications due to repair mistakes.

  Therefore, as shown in the object-oriented application 2004 in FIG. 20, the plurality of applications are integrated into the integrated application 110 by an object-oriented design method (object modeling). Specifically, a common processing part of each application is extracted as an object model, and the integrated application 110 is configured from the collection of object models. The functions such as the conventional copy function and scanner function are realized by the cooperative relationship of the object model.

  By adopting such a configuration, for example, addition of a new function such as a printer function can be dealt with by subclassing a class belonging to the object model. For this reason, a repair part becomes clear and the influence on other functions by repair can be made small. In addition, the object modeling program is easier to grasp the process than the conventional procedural program, so it is easier for the repair staff to grasp the process, reducing the scale of the repair, and other applications due to mistakes in the repair. The influence on can be reduced.

  FIG. 21 is an explanatory diagram showing the configuration of a conventional application at the stage of the service layer separated application 2002 shown in FIG. 20 and the relationship between the application and each driver of the service layer 102. As shown in the figure, the application layer 101A includes a copy application 121, a scanner application 122, a fax application 123, and a printer application 124.

  For example, the copy application 121 transmits / receives data to / from the scanner control unit 102a, the plotter control unit 102b, the accumulation control unit 102c, and the other control unit 102g in order to realize a copy function. Further, the fax application 123 performs data transmission / reception with the plotter control unit 102b, the accumulation control unit 102c, the FAX transmission / reception control unit 102e, the network communication control unit 102f, and the other control unit 102g in order to realize the fax function. As described above, communication between each application in the application layer 101A and each driver in the service layer 102 is complicated.

  Returning to FIG. 3, a plurality of applications existing in the application layer 101 are integrated into the integrated application 110 by the object modeling described above. The communication processing with each driver, which has been performed by each application overlappingly, is configured to be performed by a predetermined object model that configures the integrated application 110, so that the application of the application layer 101 and the service layer 102 of Communication between the drivers is simpler than that in FIG.

  Next, the internal configuration of the integrated application 110 will be described. FIG. 5 is an explanatory diagram showing the internal configuration of the integrated application 110 and the position of the authentication management unit 211 that is a characteristic part of the present embodiment to be described later in the integrated application 110. As shown in this figure, the integrated application 110 includes an operation system subsystem 201, a management system subsystem 202, and an execution system subsystem 203.

  The operation subsystem 201 is a software group in charge of man-machine interface. Specifically, the operation subsystem 201 performs processing for accepting a user request, processing for instructing execution of the request, and processing for providing the user with information on the execution status and execution result of the request. .

  The management subsystem 202 is a software group that manages the resources of the multifunction machine 1. Specifically, the management subsystem 202 performs a service for managing the hardware resource 151 and the data state held by the hardware resource 151.

  The execution subsystem 203 is a software group in charge of executing a request from a user. Specifically, the execution subsystem 203 performs processing from reading a document to outputting a product when a copy request is made.

  The operation subsystem 201, the management subsystem 202, and the execution subsystem 203 send processing results to each other as necessary. In this way, the subsystems cooperate to provide services required for the multifunction device 1 as the integrated application 110 as a whole.

  The management subsystem 202 includes an authentication management unit 211 that is a characteristic part of the present embodiment. The authentication management unit 211 accepts a request related to user authentication from the operation subsystem 201 or a request as to whether or not the user can execute the function when executing the function in the multifunction device 1, and authenticates the user. If the function can be executed, the fact is output to the execution subsystem 203.

  FIG. 6 is a diagram in which each subsystem shown in FIG. 5 is replaced with a UML (Unified Modeling Language) class diagram (UML class diagram). Here, UML is a system modeling language for which specifications are formulated by OMG (Object Management Group), and defines a notation for describing the results of modeling. This UML is widely used in the design of object-oriented software.

  As shown in FIG. 6, the integrated application 110 has a plurality of packages, and the integrated application 110 itself is one package. Here, the package is a grouping of each component (symbol) of the UML model, and this package is represented by a folder-type symbol with a tab on the upper left. A straight line connecting the packages indicates that there is a relationship such as a processing request between the packages.

  As shown in FIG. 6, the integrated application 110 is a package having three packages of an operation subsystem 201, a management subsystem 202, and an execution subsystem 203 inside. Furthermore, the management subsystem 202 is a package that has the authentication management unit 211 package therein. A straight line connecting the operation subsystem 201, the management subsystem 202, and the execution subsystem 203 indicates that there is a relationship such as message transmission / reception between the packages. A symbol written at the right end of the tabs of the operation subsystem 201, the management subsystem 202, and the execution subsystem 203 is a UML symbol indicating that the package is a subsystem.

  And the authentication management part 211 which is the characteristic part of this Embodiment is demonstrated in detail. Note that the authentication management unit 211 has configured an object model so that existing processing is not simply converted into an object and functions can be added or modified more easily when designing based on object orientation.

  FIG. 7 is a conceptual diagram showing the concept of processing performed by the authentication management unit 211, which is a characteristic part of the present embodiment. As shown in this figure, when there is a user authentication request from the operation system subsystem 201, authentication is performed to determine whether or not the user is a valid user by using authentication data that exists for each user. As the authentication data, for example, a user ID and a password can be considered.

  When it is determined that the user is a valid user by the authentication, a permit indicating that the user is a valid user is issued. During the period in which the permit is present, the authenticated user can execute the function of the multifunction device 1 from the operation subsystem 201. Then, after the permit is issued, when the user requests execution of the function of the multifunction device 1 from the operation subsystem 201, the permit accepts the request. Then, the license confirms whether or not the function requested for the user data is restricted. When it is confirmed that the function for which the permit is requested is not restricted, a request for executing the function is output to the active subsystem 203.

  As described above, the authentication management unit 211 which is a characteristic part of the present embodiment has a configuration in which user data and a permit are separated, and the authentication management unit 211 performs object modeling. In this way, information that varies with time such as proving that the user who uses the multifunction device 1 is an authenticated user, and static personal information such as a user ID used for collation of the user, and the like. For example, the authentication status of the user can be managed without changing the table or the like that manages the personal information of the user.

  First, as described above, the authentication management unit holds a user management unit that manages user information and an authentication certification unit that proves that the user is an authenticated user. Considering further, the information on whether or not the user can execute the function is not the personal information of the user but the information accompanying the user who uses the function. Therefore, information on whether or not a user can execute a function is managed by a function restriction unit having a configuration different from that of the user management unit. As a result, the authentication management unit separately holds the user management unit, the authentication certification unit, and the function restriction unit. Next, these configurations will be described.

  First, the authentication certification unit will be described. The authentication certification unit needs to manage a class corresponding to the above-described permit. Therefore, the authentication certification unit holds “permit class”. The permit class is a class generated when user authentication is performed using the user information managed by the user management unit. For example, the user authentication is performed at an arbitrary facility. It is the same as the permit issued in the case. That is, instead of managing the presence / absence of the login state for the user as in the past, the relationship between the user and the usage right is established with the user management unit. Thus, for example, when multiple authentications are made for a single user, multiple permit classes are issued when multiple authentications are issued by the user management unit, in the same way as multiple permits are issued. Generated, allowing the user to have multiple usage rights.

  Next, the user management unit will be described. The user management unit holds personal user information. That is, the account name and password used for authentication are also managed. Therefore, the user management unit accepts input from the operation system. In other words, the user management unit receives input from the operation system, and authenticates whether or not the user can use the function using personal information. If the user can use the function, the fact is output to the authentication certification unit.

In the user management unit, the process of accepting input from the operation system and the process using personal information are different in nature, and are therefore divided into different classes for management. In other words, the user management department
It is assumed that an “authentication list class” that receives input from the operation system and a “registered user class” that manages authentication of registered users and performs authentication and the like are held. As a result, when an input from the user is accepted, the “registered user class” is expanded in the memory only when necessary.

  Next, the function restriction unit will be described. The multifunction device 1 has functions that can be executed for each user. However, there are functions whose restrictions are determined based on the user's authority, in addition to functions whose restrictions are determined based on the user. Therefore, the function restriction unit divides them and manages them. In other words, the function restriction unit includes a “use authority sheet class” that holds a role that indicates a function restricted for each user and a user's authority, and an “access role ledger class” that holds an item restricted for each role. Hold. As a result, it is possible to collectively manage restrictions that can be shared by the user's role, and when there is a change in an item determined for each role, it is possible to change it collectively. That is, it is not necessary to set for each user, and the labor associated with the change is reduced.

  In order to authenticate the user by the authentication certification unit 211 designed by the object modeling described above, the user is connected to the operation panel 400 provided in the multifunction device 1 or the client connected to the multifunction device 1 via the network. It is necessary to log in to the multifunction device 1 from the PC. First, the operation subsystem 201 receives an input of a user ID and password of a user from the operation panel 400 or the client PC. When the operation subsystem 201 receives the input of the user ID and password, the operation subsystem 201 outputs the user ID and password to the authentication management unit 211 of the management subsystem 201 to authenticate the user.

  FIG. 8 is a diagram showing a block configuration and a class configuration of the authentication management unit 211 designed by the object modeling described above in UML classes. As shown in the figure, the authentication management unit 211 includes a user management unit 710, an authentication certification unit 720, and a function restriction unit 730. As a result, when the user management unit 710 receives an input from the operation system and is authenticated as a user having the authority to execute the function, a permit class 721 is generated in the authentication certification unit 720. When the function of the multifunction device 1 is executed, the permit class 721 that proves that the user is a legitimate user makes an inquiry to the function restriction unit 730 as to whether or not the function executed by the user is restricted. It is possible to control the functions executed by the user.

  The user management unit 710 manages the authentication name list class 711 that accepts input from the operation system such as authentication and execution of functions, and static information of users who can use the multi-function device 1. And a registered user class 712 for referring to, editing, or authenticating with the static information of the user.

  Further, the authentication certification unit 720 is generated when it is authenticated that the user can use the multifunction device 1 and whether or not the function requested by the user from the operation panel 400 or the like can be executed. A permit class 721 is provided for inquiring of the function restriction unit 730 to determine whether the user can use the function.

  In addition, the function restriction unit 730 manages the user role and the function that the user is restricted to use, and determines whether the function can be used in response to the inquiry. The use authority sheet class 731 for outputting and the access role ledger class for managing the restricted items for each role, judging whether the function can be used with the authority inputted in response to the inquiry, and outputting the judgment result 732.

  A rectangle indicating each class has three sections. From the top, a rectangle indicating a class name, an attribute section indicating data (attribute) included in the class, and an operation section indicating processing (operation) included in the class are referred to. For example, a rectangular name section indicating the authentication list class 711 indicates that the class name of the class is “authentication list”, and the attribute section indicates that the attribute of the class is “state”. The operation section indicates that the operations included in the class are “change ()”, “authentication request ()”, and “use availability confirmation ()”.

  Thus, each class has an attribute section for possessing data (attribute) and an operation section for possessing processing (operation) for writing and reading such an attribute. Since these classes are included as a part of the program (integrated application 110), when this program stored in the ROM 12a in advance is executed, each class is materialized in a predetermined area of the RAM 12b and included in the attribute section. Each data (attribute) is expanded on the RAM 12b. Therefore, the object in which the class is materialized can write and read each data (attribute) on the RAM 12b.

  In addition, if a "-" symbol is attached to the left side of a class element such as attribute or operation, this indicates that the element is private to external classes, and if a "+" symbol is attached, this element Indicates that it is open to external classes. In addition, the “()” symbol is usually attached to the operation, such as “change ()”, and an argument to be passed to the operation may be described, such as “(argument 1, argument 2)”. is there.

  Next, each class included in the authentication management unit 211 that is a characteristic part of the present embodiment illustrated in FIG. 8 will be described.

  The authentication list class 711 receives an input of authentication from the operation subsystem 201 and authenticates the user by transmitting / receiving a message to / from a registered user class 712 (to be described later). Create an object. Then, when there is a request for executing a function from the operation subsystem 201 by an authenticated user, the authentication list class 711 passes this request to the permit object 721A. Specifically, the authentication list class 711 includes a change () 711 a, an authentication request () 711 b, and an availability check () 711 c as operations.

  The change () 711 a generates an object of a registered user class 712 to be described later when an authenticated user receives a request for editing user information (for example, account name 712 a and password 712 b) from the operation subsystem 201. The user information managed by the generated registered user object 712A is changed with the information input from the operation subsystem 201. The information input from the operation subsystem 201 may be, for example, a character string indicating a new password input from the liquid crystal touch panel 420 when the change target is the password 712b. This input information is transferred to the registered user object 712 as an argument.

  The authentication request () 711 b generates a registered user object 712 </ b> A when the user makes a login request to the multifunction device 1 from the operation subsystem 201, and makes a request to authenticate the generated registered user object 712 </ b> A.

  When the authentication request () 711 b requests authentication, the user account name and password input from the operation subsystem 201 are passed as arguments. This user account name and password is input from the operation system subsystem 201 that is transmitted from a client PC connected via the network or input from the operation panel 400 of the multifunction device 1. And FIG. 9 is a diagram illustrating an example of a screen displayed on the operation panel 400 when the user logs in to the multifunction machine 1. After the screen shown in this figure is displayed, the user inputs the user name and password to log in, and then presses the 'login' button 902. As a result, the operation subsystem 201 inputs the account name and password, and inputs the account name and password input together with the request for authenticating the user to the authentication name list class 711. As a result, the authentication request () 711b can pass the account name and password as arguments.

  Returning to FIG. 8, the availability confirmation () 711 c is performed when the user logs in when there is a request to execute the function provided in the multifunction device 1 via the operation panel 400 or the client PC from the logged-in user. The usage authority sheet object 721A is requested through the registered user object 712A to confirm whether or not the function requested to be executed on the permit object 721A generated in the above can be used. The registered user object 712A and the usage authority sheet object 721A will be described later.

  When the authentication list class 711 determines that the user can use the requested function based on the confirmation result input from the permit object 721A, the authentication list class 711 outputs to the execution subsystem 203 that the function is to be executed. . As a result, the function is executed by the execution subsystem 203 only when the user is not restricted to use the function.

  The registered user class 712 manages registered user information, and performs processing using the managed user information. Specifically, the registered user class 712 includes an account name 712a, a password 712b, and a status 712c as attributes, and includes a collation () 712d, an edit () 712e, and an availability confirmation () 712f as operations. When an object that materializes the registered user class 712 is generated, the account name 712a, the password 712b, and the state 712c are expanded on the RAM 12b, so that these data (attributes) can be written and read. It becomes possible.

  The account name 712a holds an account name indicating the registered user. The password 712b holds a registered user password. Since the registered user class 712 holds the account name 712a and the password 712b, it is possible to authenticate the user who requested the login.

  As described above, by holding the account name 712a and the password 712b as attributes in the registered user class 712, the correspondence between the account name 712a and the password 712b can be held. Since the account name 712 and the password 712b may be managed so that the correspondence can be clearly understood, the password 712b is held in a class different from the registered user class 712, and the correspondence between the different class and the registered user class 712 is maintained. May be used to manage the account name 712a and the password 712b.

  The status 712c holds the usage status of the account name 712a and password 712b held by the registered user class 712. For example, 'editing', 'authenticating' or 'not used'. 'Editing' indicates that the account name 712a and password 712b are being edited according to a request from the authentication name list class 711. 'Authenticating' indicates that authentication is performed according to a request from the authentication name list class 711. And “no use” indicates a state other than the above-described states. By holding the status 712c, the registered user class 712 can manage the usage status of the account name 712a and the password 712b. As a result, for example, when authentication is performed during 'editing', the account name 712a and the password 712b are not defined, so that the registered user object 712A can perform no authentication. Therefore, the reliability of processing using user information such as the account name 712a and password 712b can be improved.

  The verification () 712 d is called from the authentication list class 711 and performs verification of registered users. Specifically, when an authentication request () 711 b is made from the authentication name list class 711, the account name and password received as arguments match the account name 712 a and password 712 b held by the generated registered user object 712 A. Whether or not is verified. Note that the state 712c becomes “authenticating” while collation is being performed. Then, by outputting the result of the verification to the authentication list class 711, it is possible to authenticate the user who made the login request.

  Edit () 712 e is called from the authentication list class 711 and edits the attribute held by the registered user object 712 A. Specifically, when an operation by the change () 711a is performed from the authentication list class 711, the account name 712a and the password 712b that are attributes of the registered user object 712A are edited using the information passed as an argument. . Note that while editing is being performed, the state 712c becomes 'editing'. That is, by providing the edit () 712e, the user's account name 712a and password 712b can be changed as necessary.

  The availability check () 712 f is called from a license object 721 A, which will be described later, and this registered user object is used to check whether the function requested by the user specified by the registered user object 712 A can be executed. A usage authority sheet object 731A corresponding to 712A is generated, and a confirmation is requested to the generated usage authority sheet object 731A.

  The permit class 721 is a class that certifies an authenticated user and requests confirmation whether or not the function requested by the user can be used. Specifically, this permit class 721 has a permission number 721a as an attribute, and has a use permission confirmation () 721c as an operation. When an object in which the permit class 721 is materialized is generated, the permission number 721a is expanded on the RAM 12b, so that these data (attributes) can be written and read.

  The permission number 721a holds the input device that has performed user authentication as a number. For example, the authorization number is held as a number from 1 to 5, and when the user is authenticated by the information input from the operation panel 400, “1” is given as the authorization number, or from the client PC via the network. When the user is authenticated, “2” to “5” are set as permission numbers. As a result, even if the same user is logged in from the operation panel 400 and the client PC at the same time, it is possible to maintain the correspondence by assigning different permission numbers, and multiple logins by the same user are possible. It is said. As a result, the same user can perform FAX transmission from the PC to the multifunction device 1 while simultaneously copying a plurality of processes, for example, on the operation panel on the multifunction device 1.

  The availability check () 721 b is called from the authentication list class 711, generates a registered user object 712 A having a corresponding relationship with the permit object 721 A, and a function requested by the user for the generated registered user object 712 A. Request to confirm whether or not When the availability check () 721b is called, the function requested by the user to be executed is received as an argument. Further, the permit object 721A requests to confirm whether or not to execute the function requested by the user, thereby collectively managing the processing executed when the user is logged in. It is no longer necessary to determine whether or not the function can be executed after determining whether or not the user is authenticated when the request to execute the function is satisfied, and the process can be simplified. It becomes possible.

  The usage authority sheet class 731 is a class that exists for each user. The usage authority sheet class 731 holds a role 731a indicating a function restricted to the user and the authority of the user, and uses a function requested by the user to execute. When a request for confirmation as to whether or not is possible is input, the result of determination based on the restricted function list 731b held as an attribute is output, or after the confirmation request is input to the access role register class 732, from the access role register This class outputs the input judgment result. Specifically, the usage authority sheet class 731 has a role 731a, a restricted function list 731b, and a state 731c as attributes, and a use permission determination () 731d and an edit () 731e as operations. When an object that materializes the usage authority sheet class 731 is generated, the role 731a, the restricted function list 731b, and the state 731c are expanded on the RAM 12b, so that these data (attributes) are written and read. It becomes possible.

  The role 731a holds the authority set for the user. The authority set for the user may be, for example, a general device administrator or a network administrator. This role 731a makes it possible to specify items restricted in the access role ledger class 732.

  The restricted function list 731b holds whether or not each user can execute each function provided in the multifunction machine 1. FIG. 10 is a diagram showing an example of the restricted function list 731b set for each user. As shown in this figure, the restricted function list 731b holds whether or not each function can be executed. As a result, when the use authority sheet class 731 receives the availability check () 731d, if the function passed as an argument is a function held in the restricted function list 731b, refer to the restricted function list 731b. Thus, it is possible to determine whether or not the user can execute.

  The status 731c holds the usage status of the restricted function list 731b held by the usage authority sheet class 731. For example, 'Editing', 'Judging' or 'Not used'. 'Editing' indicates that the restricted function list 731b is being edited from the authentication list class 711 via the registered user object 712A, and 'determining' indicates that the restricted function list 731b is used when the availability confirmation is accepted. This indicates a state where it is determined whether or not execution is possible with reference to the list 731b, and “not used” indicates a state other than the state described above. By holding such a state 712c, the usage authority sheet class 731 can manage the usage state of the restricted function list 731b. As a result, for example, when the availability check is performed during 'editing', it is determined that the restricted function is not set, and the execution of the function is not permitted for the availability check. , Reliability can be improved.

  The availability determination () 731d is called from the registered user object 712A and can be executed by the user with reference to the restricted function list 731b if the function received as an argument is a function set in the restricted function list 731b. It is determined whether or not there is, and the determination result is output to the registered user object 712A. If the received function is not a function set in the restricted function list 731b, an access role ledger object 732A is generated, and the user role received as an argument for the generated access role ledger object 732A is received. Request that the function (item) can be executed by the role. As a result, the function restricted for each user is referred to the registered user object 712A to determine whether the function can be executed, and the item set for each role is confirmed with the access role ledger object 732A. It is possible to determine whether or not the function requested by the user can be used.

  Further, when it is determined that the function requested by the user cannot be used, the availability determination () 731d outputs that fact to the authentication list class 711 via the registered user object 712A and the permit object 721A. Accordingly, the authentication name list class 711 determines that the function cannot be executed, and transmits that fact to the execution subsystem 203. FIG. 11 is a diagram showing an example of a screen displayed on the liquid crystal touch panel 420 when the function requested by the user cannot be used. As shown in the figure, by displaying that the user cannot use it, it is possible to recognize that the user has no authority to use the requested function.

  Edit () 731 e is called from the authentication list class 711 via the registered user object 712 A, and edits the attribute held by the usage authority sheet object 731 A. Specifically, when an operation by the change () 711a is performed from the authentication list class 711, the role 731a which is an attribute of the usage authority sheet object 731A is used by using the information passed as an argument to the usage authority sheet object 731A. And the restricted function list 731b is edited. If the usage authority sheet object 731A is not generated when editing the attribute, the usage authority sheet object 731A associated with the user to be edited by the registered user object 712A is generated. Accordingly, it is possible to change the attributes of the usage authority sheet object 731A, for example, the role 731a and the restricted function list 731b as necessary. While the editing is being performed, the state 731c is “editing”.

  The access role ledger class 732 corresponds to the authority management means of the present invention, manages items (functions) whose use is restricted for each role, and requests to confirm whether or not the items can be used in the role. In this class, it is determined whether or not it can be used by using a 'role and constraint correspondence' 732a held as an attribute, and this result is output. Specifically, the access role ledger class 732 has a role and constraint correspondence 732a and a state 732b as attributes, and a confirmation () 732 c and an edit () 732 d as operations. When an object that materializes the access role ledger class 732 is generated, the correspondence 732a and the state 732b of the role and the constraint are expanded on the RAM 12b, so that these data (attributes) are written and read. Is possible.

  The role-restriction correspondence 732a holds a correspondence relationship as to whether or not there is an authority to change each role in the items provided in the multifunction device 1. FIG. 12 is a diagram illustrating an example of a correspondence 732a between roles and constraints. As shown in the figure, the status of each item is set for each role. 'R' is readable, that is, the user can use the value indicated in this item, and 'W' can change the value indicated in this item. For example, a general user can connect to the set connection destination because the network is 'R', and a network administrator can change the connection destination because the network is 'RW'. Means that it is possible.

  Then, when the access role ledger class 732 is called from the confirmation () 732 c, the status of the passed item is confirmed with the role passed as an argument by referring to the correspondence 732 a between the role and the constraint, It can be confirmed whether or not a change or the like is possible.

  The state 732b holds the usage state of the correspondence 732a between the role and restriction held by the usage authority sheet class 731. For example, 'Editing', 'Checking' or 'Not used'. “Editing” indicates that the restricted function list is being edited from the authentication list class 711 via the registered user object 712A, and “confirming” indicates that the role is checked when the confirmation () 732c is called. And the constraint correspondence 732a is referred to, and it is confirmed whether or not the item can be changed, and “not used” indicates a state other than the above-described state. By holding such a state 712c, the usage authority sheet class 731 can manage the usage state of the correspondence 732a between roles and restrictions. Thus, for example, when the confirmation 732c is performed during “editing”, the confirmation processing is interrupted, and confirmation is performed using the correspondence 732a between the role and the constraint when the state is changed to a state within “editing”. Etc., and reliability can be improved.

  The edit () 732 d is called from the authentication list class 711 via the edit () 712 e of the registered user object 712 A and the edit () 731 e of the usage authority sheet object 731 A, and edits the attributes held by the access role ledger object 732 A. . Specifically, the access role ledger object generated from the usage authority sheet object 731A via the registered user object 712A and the usage authority sheet object 731A generated when the operation by the change () 711a is performed from the authentication list class 711. Using the information passed to 732A as an argument, the correspondence 732a between the role and the constraint, which is the attribute of the access role ledger object 732A, is edited. Note that while editing is in progress, the status 732b is 'editing'. As a result, it becomes possible to change the correspondence 732a between the role of the user and the restriction as necessary.

  Next, the relationship between the classes shown in FIG. 8 will be described. As shown in this figure, the straight line connecting the rectangles indicating each class indicates that there is a relationship between the classes at both ends, and the characters near the ends of this line indicate the role of the class, and the numbers indicate the class. Each multiplicity is shown. Here, the role is the role and position of the other class as seen from one class at both ends of the line, and the multiplicity is the number of objects generated from the class at both ends of the line. It is a correspondence relationship.

  For example, the role of the registered user class 712 viewed from the authentication list class 711 is “registered”, the role of the authentication list class 711 viewed from the registered user class 712 is “registration location”, and the multiplicity of the authentication list class 711 is “1” and the multiplicity of the registered user class 712 is “1. *”. Here, “1 .. *” indicates that the multiplicity of the registered user class 712 is in a range from 1 to no upper limit. For example, when “1..3” is described, the multiplicity of the class is in the range of 1 to 3.

  First, the class relationship between the authentication list class 711 and the registered user class 712 will be described. The authentication list class 711 has a role as a registration place because a user is registered with the multifunction peripheral 1 when viewed from the registered user class 712, while the registered user class 712 has a role as an authentication list class 711. It has a role as a registration target. Such a class relationship makes it possible to specify registered user information to be collated when the authentication list class 711 receives authentication or the like.

  As shown in the figure, in the scene where the authentication management unit 211 is executed, there is only one object in which the authentication name list class 711 is expanded (substantiated) on the RAM 12b, and the authentication name list class 711 is stored. There are zero or more objects in which the registered user class 712 as a target is materialized, and there is no upper limit.

  It should be noted that the authentication list class 711 is formed as a single object instead of a plurality of objects, and authentication processing from the operation subsystem 201 of the multifunction machine 1 is collectively managed. In addition, the number of objects in which the registered user class 712 is materialized indicates that the user is not logged in to the multifunction device 1, and the upper limit number of such objects is not defined. However, of course, it shall be limited by hardware specifications.

  Next, the relationship between the authentication list class 711 and the permit class 721 will be described. The permit class 721 is issued when the authentication list class 711 is authenticated as a valid user. Therefore, the authentication list class 711 has a role as a permitter when viewed from the permit class 721, while the permit class 721 has a role as a permission right when viewed from the authentication list class 711. ing.

  In addition, the authentication list class 711 has a single object, whereas the permit class 721 is a class generated every time authentication is performed. Therefore, the authentication list class 711, the permit class 721, Have a one-to-many relationship.

  Next, the relationship between the permit class 721 and the registered user class 712 will be described. Permit class 721 is issued for each authenticated user, and even if the same user is authenticated multiple times, a plurality of permits are issued for using the function. Is in a relationship. For this reason, the permit class 721 has a role as a usage right when viewed from the registered user class 712, while the registered user class 712 has a role as a user when viewed from the permit class 721. ing.

  The permit class 721 is issued for each collated user, while the user indicated by the registered user class 712 can have a plurality of permit objects 721A. The registered user class 712 and the permit class 721 have a one-to-many relationship.

  Next, the relationship between the registered user class 712 and the usage authority sheet class 731 will be described. The usage authority sheet class 731 has a restriction on functions set for each registered user. Therefore, the registered user class 712 has a role as a holder when viewed from the usage authority sheet class 731, while the usage authority sheet class 731 has a role as a possession when viewed from the registered user class 712. Have.

  In addition, since the restriction of functions held by the usage authority sheet class 731 is set for each user, the registered user class 712 and the usage authority sheet class 731 have a one-to-one relationship.

  Next, the relationship between the usage authority sheet class 731 and the access role ledger class 732 will be described. The access role ledger class 732 is a single object, not a plurality of materialized objects, and collectively holds the corresponding relationship of constraints for each role. Therefore, the access role ledger class 732 has a role as a ledger when viewed from the usage authority sheet class 731, while the usage authority sheet class plays a role as a user when viewed from the access role ledger class 732. Have.

  In addition, since there is a usage authority sheet class 731 for each user, but only one access role ledger class 732 is materialized, the usage authority sheet class 731 and the access role ledger class 732 have a many-to-one relationship. Have.

  As described above, the objects of the authentication list class 711, the registered user class 712, the permit class 721, the usage authority sheet class 731 and the access role ledger class 732 are related to each other and cooperate with each other in the authentication management unit 211. Necessary functions can be realized.

  Next, an example of the execution procedure of each class operation shown in FIG. 8 will be described. FIG. 13 is a UML sequence diagram illustrating an operation execution procedure when the authentication management unit 211 receives a login request from a user.

  Here, the UML sequence diagram will be described. Each rectangle arranged in the upper part of FIG. 13 indicates a class object. A line extending downward from each object is a line (lifeline) indicating that each object is alive, and time is considered to flow from the top to the bottom. An elongated rectangle present on this line indicates a period during which the object is actually active (active period).

  Horizontal arrows connecting the lifelines indicate execution of operations included in the object. Specifically, this arrow indicates that the original object of the arrow calls an operation included in the object at the end of the arrow. Further, when the arrow points to its own object, it means that the object calls the operation included in itself.

  As shown in FIG. 13, when the user operates the multifunction device 1 and inputs an account name and password to log in, the operation subsystem 201 receives the account name and password (step S1301). The operation subsystem 201 calls the authentication request () 711b of the authentication list object 711A to request authentication for the user to log in (step S1302).

  When receiving the login request, the authentication name list object 711A temporarily holds the passed account name and password until the authentication is completed (step S1303). Next, the authentication name list object 711A generates a registered user object 712A and calls the collation () 712d of the registered user object 712A (step S1304). At this time, the account name and password are passed as arguments. Also, generation is an operation that all objects have, and each object is materialized on the RAM 12b by generation.

  Next, the registered user object 712A for which the verification () 712d is called performs user authentication (step S1305). Specifically, the registered user object 712A determines whether the account name and password received as arguments from the verification () 712d match the account name 712a and password 712b held as attributes, and the determination result is used as the authentication name list. A message is transmitted to the object 711A.

  Next, the authentication list object 711 determines whether to generate the permit object 721A from the determination result received from the registered user object 712A (step S1306). Specifically, when a determination result indicating that the account name and the password match is received from the registered user object 712A, it is determined that the license object 721A can be generated as a login by a valid user. If a determination result indicating that they do not match is received, the authorization object 721A is not generated and the fact that the authentication has failed is output to the active subsystem 203 without being logged in by a valid user, and the process ends.

  When receiving the determination result indicating that they match, the authentication name list object 711A generates a permit object 721A corresponding to the input device that the user has requested to log in (step S1307).

  The generated permit object 721A is associated with the registered user object 712A indicating the authenticated user (step S1308). If an account name is required for association, the account name held in the authentication name list object 711A may be received. Then, while the permit object 721A is alive, the user can execute the function provided in the multifunction device 1. Then, it is confirmed whether or not the permit object 721A can use the function requested by the user. The procedure for confirming whether or not this function can be used is omitted in this sequence diagram, and will be described in detail later.

  As shown in the sequence diagram described above, in the present embodiment, when performing user authentication, the authentication list class 711, the registered user class 712, and the permit class 721 are generated and generated from each class. By authenticating from the login request with the registered object and issuing a permit associated with the authenticated user, the static data of the registered user and the dynamic data such as whether or not login is permitted Data management is facilitated by holding them separately. Further, the mechanism of such an authentication management unit is constructed by object-oriented design, and object modeling is performed based on the concept as shown in FIG. 7, and an authentication name list class 711, a registered user class 712, permission are provided as classes necessary for collation. Since the authentication management unit 211 is realized by using the certificate class 721, the software developer and software maintenance personnel can easily grasp the configuration and role of the authentication management unit, and the versatility and reliability High user authentication processing can be performed.

  Further, the execution subsystem 203 performs a process for displaying the screen shown in FIG. 11 when an authentication failure message is output.

  Next, another example of the procedure for executing each class operation shown in FIG. 8 will be described. FIG. 14 is a UML sequence diagram illustrating an operation execution procedure when the authentication management unit 211 receives a request to execute a predetermined function from a user.

  As illustrated in FIG. 14, when the user operates the multifunction device 1 and inputs to execute a predetermined function of the multifunction device 1, the operation subsystem 201 performs an operation to execute the predetermined function. Accept (step S1401). Then, the operational subsystem 201 calls the authentication list object 711A availability confirmation () 711c to request confirmation of whether the user can execute a predetermined function (step S1402). It is necessary to pass a value specifying a predetermined function requested by the user as an argument of the availability check () 711c. The same applies to the availability check () 721 b and the availability determination () 731 d shown below.

  Then, the authentication list object 711A specifies the input device that has requested execution of the function via the input device operation subsystem 201, and specifies the permit object 721A associated with the input device (step S1403). It is assumed that the permit object 721A is generated at the time of the login request shown in FIG. If the permit object 721A for the user who has requested execution of the predetermined function has not been generated, the execution is terminated assuming that the execution of the function cannot be permitted.

  Next, the authentication name list object 711A calls the specified permit object 721A with the availability check () 721b (step S1404). The permit object 721A for which the availability confirmation () 721b is called calls the associated registration user object 712A with the availability confirmation () 721b (step S1405).

  Further, the registered user object 712A called in the availability check () 721b further calls the usage authority sheet object 731A in the availability determination () 731d (step S1406). In addition, when the usage authority sheet object 731A is not yet generated when the usage authority sheet object 731A is called in the availability determination () 731d, the registered user object 712A generates the usage authority sheet object 731A and uses it after the generation. It is assumed that the call is made in the availability determination () 731d.

  Then, the use authority sheet object 731A for which the use permission determination () 731d is called determines whether or not the user who has requested the execution of the function is usable (step S1407). Specifically, when the function received as an argument is set in the restricted function list 731b, the user authority sheet object 731A determines whether or not the user authenticated from the input device from the restricted function list 731b can use this function. It is judged (step S1407). The confirmation result is transmitted to the authentication list object 711A via the registered user object 712A and the permit object 721A.

  Next, when the function received as an argument is not set in the restricted function list 731b, the usage authority sheet object 731A acquires the role 731a held as an attribute (step S1408).

  Then, the use authority sheet object 731A sets a role and a predetermined function or item requested by the user as an argument for the access role ledger class 732, and calls the access role ledger object 732A with confirmation () 732c ( Step S1409).

  Next, the access role ledger object 732A, for which the confirmation () 732 c is called, reads a predetermined item from the role and item 732 a received as an argument and the role and constraint correspondence 732 a held as an attribute, or It is confirmed whether or not writing is possible (step S1410). Specifically, it is confirmed whether or not the received role and item can be read or written by referring to the correspondence 732a between the role and the constraint as shown in FIG. Then, the access role ledger object 732A transmits the confirmed result to the authentication name list object 711A via the usage authority sheet object 731A, the registered user object 712A, and the permit object 721A.

  Then, the authentication list object 711A determines whether or not the function requested to be executed can be used based on the confirmation result in step S1407 or the confirmation result in step S1410. That the requested function is executed is output (step S1411).

  As shown in the sequence diagram described above, in the present embodiment, when authenticating a user, an authentication list class 711, a registered user class 712, a permit class 721, a use authority sheet class 731, an access It is composed of a roll ledger class 732, and after receiving a request for executing a predetermined function with an object generated from each class, it is confirmed whether or not the user can use the function, and based on the result The data is output to the execution subsystem 203. As a result, it is confirmed whether or not the permit object 721A issued to the authenticated user can execute a predetermined function. That is, the permit object 721A collectively manages the proof that the user is authenticated and the functions that can be used, thereby facilitating the management of data when the user uses the multifunction machine 1. Further, by constructing a mechanism of such an authentication management unit by object-oriented design, object modeling is performed based on the concept as shown in FIG. 7, and an authentication list is provided as a class necessary for confirming whether a predetermined function can be executed. Since the authentication management unit 211 is realized by using the class 711, the registered user class 712, the permit class 721, the usage authority sheet class 731 and the access role ledger class 732, the software developer and software maintenance personnel can manage the authentication. It is possible to easily grasp the configuration and role of the unit, and to perform user authentication processing with high versatility and reliability.

  The authentication management program executed in the image forming apparatus of the present embodiment is a file in an installable format or an executable format, and is a CD-ROM (Compact Disc Read Only Memory), a flexible disc (FD), a CD- You may comprise so that it may record and provide on computer-readable recording media, such as R (CD Recordable) and DVD (Digital Versatile Disk). In this case, the CPU 11 reads out the authentication management program from the storage medium and loads it on the MEM-P 12, thereby causing the image forming apparatus to realize each step, each unit, or each unit described above.

  The authentication management program may be provided by being stored on a computer connected to a network such as the Internet and downloaded via the network. Further, such an authentication management program may be provided or distributed via a network such as the Internet.

  The above-described configuration shows an example of a user authentication device provided with the user management unit, the authentication certification unit, and the like of the present invention, and is not limited to the above-described configuration.

  And the authentication management part 221 of this Embodiment was divided | segmented and designed for every object, and decided to provide the structure mentioned above. When this occurs, only the class etc. need to be changed. For this reason, conventionally, when the requirement increases, the work amount of the designer is also proportional to this. However, the work amount is reduced by providing the above-described configuration.

  In addition, the conventional authentication management part is designed for each application. However, the provision of the above-described configuration eliminates the concept of each application, thereby improving the design efficiency. Furthermore, when performing user authentication for each application, the same user is authenticated for each application in the same system. When using a certain application, other users are logged in to the logged-in user. There was a problem that the system could be used by impersonation. However, since the authentication management unit 221 according to the present embodiment has the above-described configuration, the concept of each application is eliminated, so that the problem that it can be used by impersonation is solved and the reliability is improved.

  By providing the above-described configuration, even when a function corresponding to an application is added, it is not necessary to design a new authentication part, and authentication is performed simply by adding whether or not the function can be used to the restricted function list 731b. It becomes possible to cope with this. This reduces the amount of work when a new function is added.

  The structure of the authentication management unit 221 is similar to a rule in which a permit is issued to a user who is permitted to use a certain facility in the real world, and the user is guaranteed by issuing the permit. . Since this concept of permit has been used for a long time in the real world, users can be managed with a stable structure even in authentication management. In addition, since the designer or user can intuitively grasp the concept of the permit, recognition until the design or use becomes easy.

(Second Embodiment)
In the authentication management unit according to the first embodiment, a message is transmitted from the permit object to the usage authority sheet class via the registered user object in order to determine whether or not the predetermined function can be executed. When the registered user object is materialized on the RAM 12b, information such as a password may be referred to by other users. Therefore, in the authentication management unit according to the second embodiment, the message is directly transmitted from the permit object to the usage authority sheet object.

  First, the second embodiment uses an authentication management unit 211 a instead of the authentication management unit 211 in FIG. 6, which is a block diagram showing the configuration of the integrated application 110 according to the first embodiment. The authentication management unit 211a will be described below.

  FIG. 15 shows a block configuration and a class configuration of the authentication management unit 211a according to the second embodiment, which is designed by the object modeling described above, and further associates the permit class and the usage authority sheet class. It is the figure shown by the class. As shown in this figure, the authentication management unit 211 according to the first embodiment described above deletes the association from the permit class 721 to the registered user class 712, and instead uses the permit class sheet 1521 from the permit class 1521. 1531 is related to 1531. In the following description, the same components as those in the first embodiment described above are denoted by the same reference numerals and description thereof is omitted.

  The registered user class 1511 manages registered user information and performs processing using the managed user information. The difference from the registered user class 712 according to the first embodiment is that the availability check () 712f is deleted as an operation. Another difference is that the relationship with the permit class 721 has been deleted.

  The permit class 1521 is a class that certifies an authenticated user and requests whether or not the function requested by the user can be used. As a difference from the registered user class 712 according to the first embodiment, an account name 1521a is added as an attribute.

  The account name 1521a holds an account name indicating the authenticated user. As a result, the permit object 1521A and the usage authority sheet object 1531A can be associated with each other.

  The availability confirmation () 1521 b is called from the authentication list class 711, generates a usage authority sheet object 1531 A having a corresponding relationship with the permit object 1521 A, and a user requests the generated usage authority sheet object 1531 A. Requests confirmation whether the function can be executed. Other contents such as arguments are omitted because they are the same as the availability check () 721b of the first embodiment.

  The usage authority sheet class 1531 is a class that exists for each user, holds a role 731a indicating a function restricted to the user and the authority of the user, and uses a function requested by the user to be executed. When a request for confirmation as to whether or not is possible is input, the result of determination based on the restricted function list 731b held as an attribute is output, or after the confirmation request is input to the access role register class 732, from the access role register This class outputs the input judgment result. The usage authority sheet class 731 according to the first embodiment is common in attribute and operation, and differs only in that it is associated with the permit class 1521.

  Next, the relationship between the classes shown in FIG. 15 will be described. In addition, description is abbreviate | omitted about the thing similar to the relationship between each class demonstrated in 1st Embodiment.

  The relationship between the permit class 1521 and the usage authority sheet class 1531 will be described. The usage authority sheet class 1531 has a restriction on functions set for each registered user. The permit class 1521 is a permit issued to the user. Therefore, the license class 721 has a role as a usage right when viewed from the usage authority sheet class 731, while the usage authority sheet class 731 has a role as a right restriction when viewed from the license class 1521. Have.

  In addition, the restriction of the function held by the usage authority sheet class 731 is set for each user, and a plurality of permit classes 721 can be issued to the user. The class 721 and the usage authority sheet class 731 have a many-to-one relationship.

  When the execution of a predetermined function is requested by this association, it is possible to confirm whether or not the user who has requested the execution of the function can use it without using the registered user object 1511A. .

  Next, an example of the execution procedure of each class operation shown in FIG. 15 will be described. FIG. 16 is a UML sequence diagram illustrating an operation execution procedure when the authentication management unit 211a receives a login request from a user.

  As shown in FIG. 16, first, in the same manner as steps S1301 to S1307 of FIG. 13 according to the first embodiment, the operation system subsystem 201 receives the account name and password until the generation of the permit object 1521A. (Steps S1601 to S1607).

  Then, the generated permit object 1521A generates a usage authority sheet object 1531A that holds the restriction of the user specified by the account name 1521a that is an attribute, and generates and associates it with the usage authority sheet object 1531A ( Step S1608).

  As shown in the above sequence diagram, in the present embodiment, when collating users, the authentication name list class 711, the registered user class 1511, the permit class 1521, and the usage authority sheet class 1531 are included. First, by performing verification from the login request with the object generated from each class, issuing a permit associated with the verified user, and further associating the permit with the usage authority sheet, the first The same effect as the flow of the sequence diagram shown in FIG. 13 of the embodiment is obtained.

  Next, another example of the procedure for executing the operation of each class shown in FIG. 15 will be described. FIG. 17 is a UML sequence diagram illustrating an operation execution procedure when the authentication management unit 211a receives a request to execute a predetermined function from a user.

  First, in the same manner as steps S1401 to S1404 in FIG. 13 according to the first embodiment, the operating system subsystem 201 accepts a request to execute a predetermined function, and then the permit object 1521A by the availability check () 721b. (Step S1701 to step S1704).

  Then, the permit object 721A that has been called to check availability () 721b further calls the availability determination () 731d to the usage authority sheet object 1531A (step S1705).

  Then, in the same manner as steps S1407 to S1411 of FIG. 17 according to the first embodiment, whether or not the function can be used in the usage authority sheet object 1531A called in the availability determination () 731d, or the usage authority sheet object After confirming whether or not a predetermined item can be read or written in the access role ledger object 732A called from 1531A, the authentication name list object 711A can determine whether or not the function requested to be executed can be used. If it is determined that the function requested by the execution subsystem 203 is executed, it is output (steps S1706 to S1710).

  As shown in the above sequence diagram, in the present embodiment, when authenticating a user, an authentication list class 711, a registered user class 1511, a permit class 1521, a usage authority sheet class 1531, an access It is composed of a roll ledger class 732, and after receiving a request for executing a predetermined function with an object generated from each class, it is confirmed whether or not the user can use the function, and the execution is performed based on the result. The data is output to the system subsystem 203. As a result, it is confirmed whether or not the permit object 721A issued to the authenticated user can execute a predetermined function. As a result, the same effect as the flow of the sequence diagram shown in FIG. 13 of the first embodiment can be obtained. Further, in the present embodiment, since the message is directly transmitted from the permit object 1521A to the usage authority sheet object 1531A without using the registered user object 1511A, the processing man-hours are reduced and the processing is reduced.

  Further, the authentication management unit 211a according to the present embodiment has the same effect as the authentication management unit 211 according to the first embodiment, and the registered user object 1511A is not expanded on the RAM 12b. It becomes possible to prevent leakage of information that should hold a secret such as the password 712b held by the object 1511A.

(Third embodiment)
In the authentication management unit according to the second embodiment, a message is sent from the license object to the usage authority sheet class without going through the registered user object in order to prevent information such as a password from being referred to by many users. I decided to send it. However, if only the confidentiality of information such as passwords is to be retained, a class for managing confidential information may be provided separately from the registered user class, and the association with the registered user class may be retained. Therefore, the authentication management unit according to the third embodiment is provided with a class for managing secret information such as a password held by the registered user class.

  First, the third embodiment uses an authentication management unit 211b instead of the authentication management unit 211 in FIG. 6 which is a block diagram showing the configuration of the integrated application 110 according to the first embodiment. The authentication management unit 211b will be described below.

  FIG. 18 shows a block configuration and class of the authentication management unit 211b according to the third embodiment, which is designed by the object modeling described above, and further includes a secret information class that holds secret information separately from the registered user class. It is the figure which showed the structure by the class of UML. As shown in the figure, the authentication management unit 211 according to the first embodiment described above has a configuration in which a secret information class 1812 is newly provided and associated with the registered user class 1811. In the following description, the same components as those in the first embodiment described above are denoted by the same reference numerals and description thereof is omitted.

  The registered user class 1811 is a class for managing information of registered users. The registered user class 712 according to the first embodiment is different from the registered user class 712 in that the password 712b is deleted as an attribute, and the operation has a verification () 1811a that is different from the verification () 712d. Furthermore, it is different in that it is associated with the secret information class 1812.

  The verification () 1811 a is called from the authentication list class 711, and checks whether or not the user who has requested authentication is a registered user. Specifically, when called from the authentication name list class 711 and receiving an account name and password as arguments, it is determined whether or not the account name received as an argument matches the account name 712a held. If it is determined that they match, a secret information object 1812A is further generated, a password is passed as an argument to the generated secret information object 1812A, and password verification is requested. And it is collated whether it corresponds with the registered user from the result input from the secret information object 1812A. Note that the state 712c is “verifying” while collation is being performed. Then, by outputting the result of the verification to the authentication list class 711, it is possible to authenticate the user who made the login request. After the password verification is completed, the secret information object 1812A is deleted from the RAM 12b. This makes it possible to prevent leakage of secret information.

  The secret information class 1812 is a class for managing secret information of registered users. Specifically, the secret information class 1812 has a password 1812a and a state 1812b as attributes, and a collation () 1812c and an edit () 1812d as operations. When an object that materializes the secret information class 1812 is generated, the password 1812a and the state 1812b are expanded on the RAM 12b, so that these data (attributes) can be written and read.

  The password 1812a holds the password of the registered user. By holding the password 1812a in the secret information class 1812, it is possible to verify the user who requested the login.

  The state 1812b holds the use state of the password 1812a held by the secret information class 1812. For example, 'editing', 'verifying' or 'not used'. 'Editing' indicates that the password 1812a is being edited by a request via the registered user class 1811. 'Verifying' is called from the registered user class 1811 with the verification () 1812c to perform verification. And “no use” indicates a state other than the above-described state. By holding such a state 712c, the secret information class 1812 can manage the use state of the password 1812a. As a result, for example, when authentication is performed during ‘editing’, the password 1812a is not determined, so the secret information class 1812 improves the reliability by not verifying the password 1812a.

  The verification () 1812 c is called from the registered user class 1811 and performs password verification. Specifically, when it is called from the registered user class 1811 and a password is received as an argument, it is checked whether or not the password received as an argument matches the password 1812a held, and the result is registered user class 1811. Send to. Note that the state 712c is “verifying” while the verification is being performed. Then, by outputting the result of the verification to the registered user class 1811, it is possible to authenticate the user who made the login request.

  Edit () 1812 d is called from the authentication list class 711 via the registered user class 1811 and edits the attribute held by the secret information object 1812 A. Specifically, when called from the registered user class 1811 and receiving a password as an argument, the password 1812a held as an attribute is edited. Note that while editing is being performed, the state 712c becomes 'editing'. This makes it possible to change the user password 712b as necessary.

  In this embodiment, the password 1812a and the state 1812b are used as the attributes held by the secret information class 1812. However, for example, if the information is to be prevented from being leaked, such as an address or a telephone number, it is held as an attribute of the secret information class 1812. good.

  Next, the relationship between the classes shown in FIG. 18 will be described. In addition, description is abbreviate | omitted about the thing similar to the relationship between each class demonstrated in 1st Embodiment.

  The relationship between the registered user class 1811 and the secret information class 1812 will be described. The registered user class 1811 manages information of registered users. The secret information class 1812 is a person who manages information that needs to prevent leakage of registered users. Therefore, the registered user class 1811 has a role as a holder when viewed from the secret information class 1812, while the secret information class 1812 has a role as a possessed when viewed from the registered user class 1811. ing.

  Further, since the information held by the secret information class 1812 is set for each user, the registered user class 712 and the secret information class 1812 have a one-to-one relationship.

  Next, an example of the execution procedure of each class operation shown in FIG. 18 will be described. FIG. 19 is a UML sequence diagram illustrating an operation execution procedure when the authentication management unit 211b receives a login request from a user.

  As shown in FIG. 19, first, in the same manner as steps S1301 to S1304 of FIG. 13 according to the first embodiment, after the operating system subsystem 201 accepts an account name and password, a registered user object is obtained by verification () 1811a. Processing up to calling 1811A is performed (steps S1901 to S1904).

  Then, the account name received as an argument from the collation () 712d is collated with the account name 712a held by the registered user object 1811A (S1905). If they do not match in the verification, the user who is requested to log in transmits information indicating that the user is not registered to the authentication name list object 711A, and determines that the received authentication name list object 711A cannot generate the permit object 721A (step In step S1908, the execution subsystem 203 is notified that the authentication has failed, and the process ends.

  If the account names match, the registered user object 1811A generates the secret information object 1812A, and calls the secret information object 1812A check () 1812c using the received password as an argument (step S1906).

  Then, the password received as an argument from the collation () 1812c is collated with the password 1812a held by the secret information object 1812A (S1907). If they do not match, the fact that the registered user has requested unauthorized login is transmitted to the authentication name list object 711A, and the received authentication name list object 711A determines that the permit object 721A cannot be generated (step S1908). . Then, the authentication list object 711A outputs a message indicating that the authentication has failed to the active subsystem 203 and ends. As soon as collation is completed, the registered user object 1811A deletes the secret information object 1812A from the RAM 12b.

  If the passwords match, the fact is transmitted to the authentication name list object 711A. The received authentication name list object 711A determines to generate the permit object 721A (step S1908).

  Then, a permit object 721A is generated in the same manner as steps S1307 to S1308 of FIG. 13 according to the first embodiment, and the generated permit object 721A associates (steps S1909 to S1910).

  As shown in the above sequence diagram, in the present embodiment, when collating users, the authentication name list class 711, the registered user class 1511, the permit class 1521, and the usage authority sheet class 1531 are included. The flow of the sequence diagram shown in FIG. 13 of the first embodiment by collating from the login request with the object generated from each class and issuing a permit associated with the collated user Has the same effect as. Further, when the collation is completed, the secret information object 1812A is deleted, thereby preventing the leakage of secret information such as a password.

  The operation when the authentication management unit 211 receives a request to execute a predetermined function from the user is the same as the execution procedure shown in FIG.

  Further, the authentication management unit 211b according to the present embodiment has the same effect as the authentication management unit 211 according to the first embodiment, and further receives a request for executing a predetermined function from the user. Although the registered user object 1511A is expanded on the RAM 12b, the secret information object 1812A is not generated and thus is not expanded on the RAM 12b. Thus, it is possible to prevent leakage of information such as the password 1812a that should be kept secret.

As described above, the image processing apparatus, the user authentication method, and the user authentication program according to the present invention are useful for user authentication, and in particular, using an authentication certification unit generated after authentication is performed. It is suitable for a technique for determining whether or not an application requested by a user can be used.

1 is a network diagram for explaining a network environment surrounding a multifunction peripheral according to a first embodiment. FIG. 1 is a block diagram illustrating a hardware configuration of a multifunction machine according to a first embodiment. FIG. FIG. 3 is a conceptual diagram for explaining a relationship between software and hardware of the multifunction peripheral according to the first embodiment. 3 is a diagram illustrating an example of an operation panel of the multifunction peripheral according to the first embodiment. FIG. 3 is an explanatory diagram illustrating an internal configuration of an integrated application of the multifunction peripheral according to the first embodiment and a position of an authentication management unit in the integrated application. FIG. It is a UML class diagram about each subsystem shown as an internal configuration of the integrated application of the multifunction peripheral according to the first embodiment. 3 is an explanatory diagram illustrating an outline of processing of an authentication management unit included in the multifunction peripheral according to the first embodiment. FIG. FIG. 3 is a diagram illustrating a block configuration of an authentication management unit and a UML class configuration of the multifunction peripheral according to the first embodiment designed by object modeling. It is the figure which showed an example of the login screen of the user displayed on the liquid crystal touch panel of the multifunctional device which concerns on 1st Embodiment. It is the figure which showed an example of the restriction | limiting function list set for every user which the utilization authority sheet | seat class with which the authentication management part of the multifunctional device concerning 1st Embodiment is equipped as an attribute. It is the figure which showed an example of the screen displayed on a liquid crystal touch panel when the function requested | required by the user is not performed. It is the figure which showed the response | compatibility with the role which the access role ledger with which the authentication management part of the multifunctional machine concerning 1st Embodiment is equipped as an attribute has restrictions. FIG. 10 is a UML sequence diagram illustrating an operation execution procedure when the authentication management unit of the multifunction peripheral according to the first embodiment receives a login request from a user. FIG. 10 is a UML sequence diagram illustrating an operation execution procedure when the authentication management unit of the multifunction peripheral according to the first embodiment receives a request to execute a predetermined function from a user. The block diagram of the authentication management unit of the MFP according to the second embodiment, which is designed by object modeling and further associates the permit class and the usage authority sheet class, and the class configuration are shown as UML classes. is there. FIG. 10 is a UML sequence diagram illustrating an operation execution procedure when an authentication management unit of a multifunction peripheral according to a second embodiment receives a login request from a user. FIG. 10 is a UML sequence diagram illustrating an operation execution procedure when an authentication management unit of a multifunction peripheral according to a second embodiment receives a request for executing a predetermined function from a user. The block configuration and class configuration of the authentication management unit of the MFP according to the third embodiment, which is designed by object modeling and further provided with a secret information class that holds secret information separately from the registered user class, is a UML class. FIG. FIG. 10 is a UML sequence diagram illustrating an operation execution procedure when an authentication management unit of a multifunction peripheral according to a third embodiment receives a login request from a user. FIG. 6 is an explanatory diagram for explaining a transition of a software configuration installed in a multifunction peripheral. It is explanatory drawing for demonstrating the relationship between the software of the conventional multifunction peripheral, and hardware.

Explanation of symbols

1 MFP 10 Controller 11 CPU
12 System memory (MEM-P)
12a ROM
12b RAM
13 North Bridge (NB)
14 South Bridge (SB)
15 AGP bus 16 ASIC
17 Local memory (MEM-C)
18 Hard disk drive (HDD)
20 Keyboard 30 FCU
40 USB
50 IEEE1394 interface 60 Engine unit 100 Software 101, 101A Application layer 102 Service layer 102a Scanner control unit 102b Plotter control unit 102c Storage control unit 102d Distribution / mail transmission / reception control unit 102e FAX transmission / reception control unit 102f Network communication control unit 102g Other control units DESCRIPTION OF SYMBOLS 103 Operating system 110 Integrated application 121 Copy application 122 Scanner application 123 Fax application 124 Printer application 150 Hardware 151 Hardware resource 151a Scanner 151b Plotter 151c HDD
151d Network 151e Other Resources 201 Operation Subsystem 202 Management Subsystem 203 Execution Subsystem 211, 211a, 211b Authentication Management Unit 400 Operation Panel 401 Initial Setting Key 402 Copy Key 403 Copy Server Key 404 Printer Key 405 Transmission Key 406 Numeric keypad 407 Clear / stop key 408 Start key 409 Preheating key 410 Reset key 420 LCD touch panel 710 User management unit 711 Authentication list class 711a Change ()
711b Authentication request ()
711c Check availability ()
711A Authentication list object 712, 1511, 1811 Registered user class 712a Account name 712b Password 712c Status 712d, 1811a Verification ()
712e edit ()
712f Check availability ()
712A, 1511A, 1811A Registered user object 720 Authentication certification part 721, 1521 Permit class 721a Permit number 721b, 1521b Confirmation of availability ()
721A, 1521A Permit object 730 Function restriction unit 731, 1531 Usage authority sheet class 731a Role 731b Restricted function list 731c Status 731d Availability judgment ()
731e Edit ()
731A, 1531A Usage authority sheet object 732 Access role ledger class 732a Correspondence between role and restriction 732b Status 732c Confirmation ()
732d edit ()
732A Access role ledger object 902 'Login' button 1101 Function restriction warning window 1521a Account name 1812 Secret information class 1812a Password 1812b Status 1812c Verification 1812d Edit 1812A Secret information object 2001 Application before service layer separation 2002 Application after service layer separation 2003 Common routine separation Application 2004 Object Oriented Application

Claims (17)

An image processing apparatus in which a plurality of applications cooperate to execute image processing ,
Manages user information indicating a user who can use the device, receives an authentication request as to whether or not the user is the usable user from the input means, and the user based on the user information User management means for authenticating
Authentication certificate before SL user a license to be a proof of the authenticated user in the user management unit, issuing a permit which is associated with the input means performing the authentication request Means,
Manage User function correspondence information indicating the user executable for each of the application, the license is issuer confirm whether it is possible to execute a predetermined application to work in the execution of the image processing A function restriction unit that accepts a request from the permit, and confirms whether the user can execute the predetermined application based on the user function correspondence information;
With
The permit is the input means associated with the permit for confirming whether or not the user to whom the permit has been issued can execute a predetermined application that cooperates in the execution of image processing. And output to the function restriction means,
The authentication certification unit outputs to the predetermined application a determination result as to whether or not the user can execute the predetermined application based on a confirmation result of the function limiting unit. Processing equipment. The user management means includes
An authentication name list means for accepting an edit request of the user information from the input means or an authentication request as to whether or not the user is the usable user;
Registered user means for managing the user information and editing the user information or authenticating the user based on the user information;
The image processing apparatus according to claim 1, further comprising: The user management means manages user secret information indicating the user's secret information, and when receiving a process using the user secret information, the secret information for performing the process using the user secret information Means further comprising
The image processing apparatus according to claim 2, wherein the authentication list unit included in the user management unit receives a processing request using the user secret information from the input unit. The registered user means included in the user management means manages use state information indicating a use state of the user information, and changes the use state information in response to a processing request received. Item 4. The image processing apparatus according to Item 2 or 3. The function restriction unit manages authority function correspondence information indicating the authority of the executable user for each of the application, the predetermined application certified user to cooperate to perform image processing in the authentication certificate means An authority management unit that accepts a confirmation request as to whether or not the user is capable of executing and confirms that the user can execute the predetermined application based on the authority function correspondence information. The image processing apparatus according to claim 1, wherein: The function restricting means can execute a predetermined application that cooperates to execute predetermined image processing by a user whose permit information is issued by the authentication certification means from the authentication certification means via the registered user means. Accepting a request for confirmation of whether or not
The image processing apparatus according to claim 2, wherein the authentication certification unit receives a confirmation result from the function restriction unit via the registered user unit from the function restriction unit. The function restricting means is a user who can execute a predetermined application in cooperation with a user whose permit information is issued by the authentication proving means directly from the authentication proving means to execute predetermined image processing. Accepts a request to check if
The image processing apparatus according to claim 1, wherein the authentication certification unit receives a confirmation result of the function restriction unit directly from the function restriction unit. The user management means receives an authentication request as to whether or not the same user is the usable user from a plurality of input means, and authenticates the same user based on the user information. For each of the plurality of input means,
The said authentication certification | authentication means issues the permit information used as the proof that the same said user is the user who was authenticated by the said user management means for every said input means, The said 1st aspect is characterized by the above-mentioned. 8. The image processing apparatus according to any one of 7. The image processing apparatus according to claim 8, wherein the authentication certification unit issues a different permission number for each input unit. A user authentication method executed by an image processing apparatus in which a plurality of applications cooperate to execute image processing ,
User management means manages user information indicating a user who can use the device, receives an authentication request as to whether the user is the usable user from the input means, and receives the user information. A user management step for authenticating the user based on:
Authentication credentials means, a permit the previous SL user is proof of the user authenticated by the user management step, the authentication request a permit which is associated with input means went An authentication certification step for issuing
The function restriction unit manages user function correspondence information indicating a user that can be executed for each application , and a user to whom the permit is issued can execute a predetermined application that cooperates in executing image processing. or accepted whether or not a confirmation request from the license, the function restriction steps of the user based on the user function corresponding information to confirm whether it can execute the predetermined application,
In the function restriction step, when the permit issues a confirmation request as to whether or not the user to whom the permit has been issued can execute a predetermined application linked with the execution of image processing, A permit step for receiving from the input means associated with the certificate and outputting to the function restriction means;
It said authentication proof means, and an output step of the user based on the check result of the previous SL function restriction step outputs a determination result whether it is capable of executing the predetermined application to the predetermined application,
User authentication method characterized by having a. In the user management step,
An authentication list step for accepting an authentication request as to whether the authentication list means is editing the user information from the input means or whether the user is the usable user;
A registered user means for managing the user information, editing the user information, or authenticating the user based on the user information;
The user authentication method according to claim 10, further comprising: The user management step manages the user secret information indicating the user secret information, and when receiving the process using the user secret information, the secret information for performing the process using the user secret information Further comprising a step,
12. The user authentication method according to claim 11, wherein the authentication list step included in the user management step accepts a processing request using the user secret information from the input means.   The registered user step included in the user management step manages use state information indicating a use state of the user information, and changes the use state information in response to a processing request received. Item 13. The user authentication method according to Item 11 or 12. The function restriction step is to manage permissions function correspondence information indicating the authority of the executable user for each of the application, the authentication certificate means a predetermined application certified user to cooperate to perform image processing with An authority management step of accepting a confirmation request as to whether or not the user is capable of executing and confirming that the user can execute the predetermined application based on the authority function correspondence information. The user authentication method according to any one of claims 10 to 13. In the function restriction step, a user whose permit information is issued by the authentication certification means from the authentication certification means via the registered user means can execute a predetermined application that cooperates to execute image processing. Accepts a request to confirm whether or not
14. The user authentication method according to claim 11, wherein the authentication certification step receives a confirmation result in the function restriction unit from the function restriction unit via the registered user unit. . The user management step accepts an authentication request as to whether or not the same user is the usable user from a plurality of input means, and authenticates the same user based on the user information. For each of the plurality of input means,
16. The authentication certification step issues license information for proof that the same user is a user authenticated in the user management step for each of the input means. The user authentication method described. A user authentication program for causing an image processing apparatus to execute the user authentication method according to any one of claims 10 to 16.

Images