JP6007646B2 - Printing apparatus, additional embedded software processing apparatus, and additional embedded software execution control method - Google Patents

Description

The present invention relates to a printing apparatus, an additional embedded software processing apparatus, and an additional embedded software execution control method .

  Conventionally, it is known that small software called add-ons (or plug-ins) for the purpose of function expansion or customization can be added to the software body of general information processing devices. There is a controller having control software in which add-on software can be added in the same way. Here, the add-on, plug-in, and the like are collectively referred to as additional embedded software.

Control software that can add additional embedded software, such as add-on software, generally provides various component software for add-on software, etc. Realize functions, custom display and operation. Therefore, a creator of add-on software or the like can increase the degree of freedom as the number of types of components to be provided and the processing targets increase and the number of objects to be processed increases.
For example, Patent Document 1 discloses a technique for controlling permission / prohibition of input / output of add-on software using user authority information set in advance by an information processing apparatus or the like.

JP 2009-87283 A

However, in the above-described prior art, the risk of security due to add-on software and the like increases as the scope of parts handled by the additional embedded software processing device increases and the processing content increases, but this is managed and prevented. There was a problem that there was no way to do.
Among the additional embedded software processing devices, especially in the case of printing devices, the control software itself often has a security function for print data, but this function is not intended for add-on software and is effective. It can not be said.
For this reason, it is impossible to prevent problems such as improper access / falsification / leakage to print data, user information, logs, etc., or damage to the control software, regardless of whether or not malicious software was created. There was a problem.

An object of the present invention is to provide a printing apparatus, an additional embedded software processing apparatus, and an additional embedded software execution control method capable of preventing inappropriate data access, falsification, leakage, and the like caused by the additional embedded software. .

According to the present invention, there is provided a software component storage unit for storing a plurality of software components including a program for executing a function process, and additional embedded software including a program for executing a combination of at least two of the software components. Additional embedded software registration unit registered from the outside, user authority storage unit that stores the authority level of the additional embedded software for each user in advance, and additional embedded software registered by the additional embedded software registration unit When the user tries to execute, the user authority level acquisition unit for identifying the user and acquiring the authority level for the user from the user authority storage unit, and processing according to the execution of the additional embedded software A risk level determination unit that determines a risk level corresponding to execution of the additional embedded software for each software component; Based on the authority level acquired by the executor authority level acquisition unit corresponding to the embedded software and the risk level for each software component determined by the risk level determination unit, the software component This can be achieved by providing a printing apparatus, an additional embedded software processing apparatus, and an additional embedded software execution control method characterized by including a software component execution control unit that determines whether or not to permit execution .

According to the printing apparatus, the additional embedded software processing apparatus, and the additional embedded software execution control method of the present invention, it is possible to prevent inappropriate data access, falsification, leakage, and the like by the additional embedded software.

1 is an overall configuration diagram of a printing system of this example. It is a figure which shows the process example implement | achieved by app. It is a process flowchart figure at the time of registration of app to a printing apparatus. It is a figure which shows an example of a user authority table. It is a figure which shows the specific example of various components. It is a flowchart figure which shows the specific example of the process performed by app. It is a common flow executed every time each part is executed.

FIG. 1 is an overall configuration diagram of a printing system showing an example of an additional embedded software processing apparatus according to the present invention.
Note that FIG. 1 may be regarded as a detailed configuration diagram of a printing apparatus (additional embedded software processing apparatus) constituting the printing system.
The printing system of this example has a configuration in which a printing apparatus 1 and a PC (personal computer) 4 are connected by a communication line (not shown; LAN or the like). For example, print data sent from the PC 4 is transferred to the printing apparatus 1. To execute printing.
The printing apparatus 1 includes a controller 2 and a print engine 3. Although not particularly shown, the print engine 3 has, for example, a developing device, a fixing unit, a paper transport mechanism, and the like, and is a unit having a function of printing on paper under the control of the controller 2, and is the same as the conventional one. I will not explain any more here.

Although not particularly shown, the controller 2 has a CPU, a storage unit, etc., the main unit software 10 (program) is stored in the storage unit, and additional embedded software (hereinafter referred to as “app”). 20 is additionally stored. For example, the CPU (not shown) executes the main body software 10 to realize, for example, the processing functions of the various functional units 11 to 17 shown in FIG.
That is, the controller 2 includes an operation panel control unit 11, an engine control unit 12, a command processing / drawing unit 13, a print control unit 14, and the like. The controller 2 further includes a user authority management unit 15, a disk control unit 16, an app control unit 17, and the like. These various functional units use, for example, various component software (program component / software component; hereinafter simply referred to as a component) shown in FIG. These various “components” can be used even if they are app20 if permitted. The determination as to whether or not to permit is performed by, for example, the processing of FIG. 7 described later, and will be described later.

The operation panel control unit 11 performs some display for the user and accepts an instruction / input from the user. The engine control unit 12 monitors the status of the print engine 3 and performs print settings. The command processing / drawing unit 13 receives print data from the PC 4 and performs drawing based on the print data. The print control unit 14 sends the drawn image to the print engine 3 to control printing.
Further, the user authority management unit 15 and the disk control unit 16 manage user authority of the printing apparatus 1. The disk control unit 16 controls a nonvolatile memory (not shown).
In addition, in the printing apparatus 1, software (app20) called add-on or plug-in for adding a function not included in the controller built-in software (main body software 10) (or customizing it so that it can be easily used by the user). Addition and incorporation are possible, and the app control unit 17 controls the app 20.

  Here, the above-described add-on, plug-in, and the like are examples of small-scale software that is arbitrarily added to or incorporated into the printing apparatus 1 (its main body software 10) as described above. Such small-scale software is referred to as “additional embedded software”. The printing apparatus 1 of this example has a control software main body (main body software 10 or the like), and implements an arbitrary processing function using various parts used in the control software main body. Software) ". In this description, the additional embedded software processing device will be described by taking an add-on (app20) as an example of such “additional embedded software (additional embedded software)” as an example.

In addition, in order to distinguish from app20 which is an example of additional embedded software, here, the controller built-in software group which implement | achieves the various function parts of the said operation panel control part 11-app control part 17 is called the main body software 10 as above-mentioned. Although not shown, the printing apparatus 1 has an arithmetic processor such as a CPU. The CPU reads and executes the controller built-in software group to realize the various functional units. The app 20 is also executed by the CPU.
FIG. 2 shows an example of an additional function realized by app20.
In the app 20 of this example, when a user sends a plurality of print data (in this example, a plurality of catalogs A, B, and C) from the PC 4 to the printing apparatus 1, the plurality of print data is sent to the operation panel on the printing apparatus 1 side. Using a user interface such as an (operation panel), customization or the like is performed so that printing can be performed collectively or selected.

In this example, the illustrated print menu screen 30 is first displayed on a user interface (display, touch panel, etc.). In the illustrated example, the print menu screen 30 displays three buttons: a “collective print” button 31, an “individual print” button 32, and an “end” button 33. If the “collective print” button 31 is pressed by a user operation, all registered print data (for example, all catalogs A, B, and C) are printed. On the other hand, when the “individual print” button 32 is pressed, the display of the user interface is changed to the illustrated individual selection menu 40.
A plurality of print data (three catalogs A, B, and C in the illustrated example) are displayed on the individual selection menu screen 40, and the data (catalog) selected by the user operation is printed.

When the “end” button 33 of the print menu is pressed, the function of this app 20 is ended.
In this method, an arbitrary app 20 can be additionally registered in the printing apparatus 1 at an arbitrary time. In this method, anyone can register the new app 20 itself without any particular limitation. However, as will be described later, for example, when executing some function of the app 20 registered in the printing apparatus 1 at the time of executing printing, the app 20 is based on the authority of the app registrant and the authority of the executor (for example, the print executor). Whether to execute or not is determined. Therefore, there are cases where the execution of app20 is not permitted. For example, permission / non-permission of execution (use) may be determined for each of various parts used by the app 20. Details will be described later.

FIG. 3 is a flowchart showing an outline of processing at the time of registration of app 20 to the printing apparatus 1 and subsequent execution of app. Note that this processing is realized by the controller 2 using the functions of the various functional units, for example. Note that the processing of FIG. 6 to be described later can also be realized by the controller 2 (its CPU) executing app20. 7 can be said to be realized by the controller 2 (its CPU) (for example, by executing various components).
FIG. 6 to be described later shows a specific example of the app execution process in step S16 of FIG. FIG. 7 described later is a process executed for each component execution in FIG. 6, and there is a case where execution / use of the component is not permitted.
Hereinafter, FIG. 3 will be described first.
First, when the printing apparatus 1 is turned on, the printing apparatus 1 is activated (step S11). At that time, the controller 2 in the printing apparatus 1 is also activated at the same time, and is ready to receive data from the PC 4.

Thus, when any data transmitted from the PC 4 is received thereafter (step S12, YES), the command processing / drawing unit 13 determines the data type. That is, it is determined whether the received data is print data or app registration data (app program) (step S20). For example, the received data includes identification information indicating whether the data is print data or app registration data. The identification information is transmitted by the PC 4 being attached to the data when the user performs a designation operation on the PC 4, for example.
If the received data is print data (YES in step S20), a print process for the print data, which is a normal process, is performed (step S23).

On the other hand, if it is determined that the received data is app registration data (NO in step S20), the transmission source user of the app registration data is specified, and the user authority management unit 15 is inquired about the app authority level of the user and acquired. To do.
Some user identification methods including identification of the transmission source user include, for example, a host name (or IP address or the like) included in data sent from the PC 4 or a device such as an IC card reader attached to the printing apparatus 1. The user name is determined from the obtained user identification information.
That is, for example, a host name and a user name are registered in advance in a user registration table (not shown), and a user name corresponding to the host name of the transmission source PC 4 is acquired.

  Alternatively, in the case of a printing system that performs so-called “pull printing”, for example, an IC card reader is provided in the printing apparatus 1 and the user inserts his / her IC card, so that an ID (user identification information; An employee number or the like is read out and printing is performed using this ID. The ID itself may be the user name, or a table (not shown) in which the ID and the user name are associated in advance is provided, and the user name of the print performer or the like is acquired by referring to this table. You may do it.

The user authority management unit 15 holds a user authority table 50, and determines the app authority level of the transmission source user by referring to this (step S21).
FIG. 4 shows an example of the user authority table 50.
The user authority table 50 in the illustrated example includes a user name 51, a print authority 52, and an app authority 53. The print authority 52 designates a user level related to printing, such as whether or not color printing is possible, and is not particularly relevant here, and will not be described further.
In the user authority table 50, the app authority 53 of the user is registered corresponding to each user name 51. This app authority level 53 is an authority level given to each user regarding the operation of registration and execution of app. In the illustrated example, the app authority 53 is a numerical value such as 0, 1, 2, 5, and the like. In this example, the higher the numerical value, the greater the authority.

The user authority management unit 15 reads the user's app authority level (corresponding app authority 53) from the user authority table 50 using the user name of the identified transmission source user. This means that the app authority level of the registrant of the app registration data (app program) is acquired here.
Thus, the app authority level (registrant authority level) of the app registrant is attached to the received app registration data, sent to the disk control unit 16, and stored in a nonvolatile memory (not shown) or the like (step S22).
Thus, the process at the time of registering arbitrary app data ends. By this process, as described above, the app registration level (registrant authority level) of the registrant is added to the app registration data (app20) stored in the non-illustrated nonvolatile memory or the like. This registrant authority level is referred to later in the process of FIG. Details will be described later.

In the case of the example in FIG. 2, the app registration data includes the screens of the print menu 30 and the individual selection menu 40, and programs related to various operations on these screens. Further, data of catalogs A, B, and C shown in FIG. 2 may be included.
The above-described processing is processing when there is an event for receiving data from the PC 4, but the command processing / drawing unit 13 determines that the operation panel control unit 11 or the like does not receive data (step S12, NO). Queries whether there is an app activation instruction. If there is no app activation instruction (NO in step S13), the process returns to the data reception waiting state in step S12. However, if there is an application activation instruction (YES in step S13), the app control unit 17 is activated to perform step S14. The subsequent processing is controlled.

Although not particularly illustrated, the printing apparatus 1 also has a function of selecting and specifying execution of arbitrary add-on software among registered add-on software (app20). The determination in step S13 is YES.
The app control unit 17 first identifies a user (app executor) who has given an app activation instruction. Since the user specifying method has already been described in the explanation at the time of app registration, it is omitted here. Then, the app authority level (executor authority level) of the app executor is acquired (step S14). For example, by referring to the user authority table 50 by the user authority management unit 15 or the like, the app authority 53 (executor authority level) corresponding to the user name 51 of the app executor is acquired.

Further, the app control unit 17 requests the disk control unit 16 to read out the app registration data (app program) instructed to be activated (step S15). As described above, the registrant authority level is added to each app program (app20). Then, the app 20 is activated and executed (step S16). At that time, the app control unit 17 gives the app 20 the registrant authority level and the executor authority level as arguments (arguments).
FIG. 6 shows a specific example of the app execution process in step S16. This specific example is an example in which various components 500 to 511 shown in FIG. 5 are used as the “component”. Thus, the specific example shown in FIG. 5 will be described before the description of FIG.

FIG. 5 is a diagram illustrating specific examples of various components.
In FIG. 5, reference numerals 500 to 511 denote various “components” that are available libraries or the like prepared in advance for the various function units 11 to 16 of the main body software 10. In the illustrated example, for example, the operation panel control unit 11 executes the above-described processing using components such as the “display” component 500 and the “input” component 501.
In addition, for example, a “file print instruction” component 502, a “security print setting” component 503, an “authorization information acquisition” component 504, an “authorization information change” component 505, a “file write” component 506, and a “file read” are illustrated. "Part 507", "Engine status display" part 508, "Engine setting change" part 509, "Print start" part 510, "Print log display" part 511, etc. are prepared and stored.
As shown in FIG. 5, the app 20, which is externally created additional software, uses the components 500 to 511, which are available libraries and the like prepared for various functions of the main body software 10. Control and build new functions. For example, the process shown in FIG. 6 is executed, but of course, the present invention is not limited to this example.

FIG. 6 is a flowchart showing a specific example of processing executed by the app 20.
This specific example is, for example, app 20 that executes the processing function of FIG.
Hereinafter, the processing example of FIG. 6 will be described.
Here, in FIG. 6, the numbers (500, 501 etc.) shown in the steps other than steps S33 and S37 mean the symbols (500, 501 etc.) of the parts shown in FIG. This means that the process is executed.

In FIG. 6, as described above, the registrant authority level and the executor authority level are given at the start of processing execution. First, the operation panel control unit 11 is requested to display the print menu 30 of FIG. 2 using the “display” component 500 (step S31). However, this is a process when the use of the “display” component 500 is permitted. When the use is not permitted, the process of step S31 is not performed. The same applies to steps S32, S34 to S36, S38 to S42 and the like which will be described later. Permission / non-permission is determined by the processing of FIG. The details will be described later, and first, the processing of FIG. 6 will be described, but this is premised on all cases being permitted.
That is, first, when the user operates an arbitrary button on the print menu 30 displayed by the process of step S31, a process for detecting this is performed. That is, the button selected by the operation panel control unit 11 is read using the “input” component 501 (step S32), and the selected button is determined (step S33).

In the example of FIG. 2, as described above, the “collective print” button 31, the “individual print” button 32, and the “end” button 33 are displayed, and if the “end” button 33 is selected. This process ends. On the other hand, if the “collective print” button 31 is selected, the processes of steps S34 to S37 are executed, and if the “individual print” button 32 is selected, the processes of steps S38 to S42 are executed.
When batch printing is selected, first, the disk control unit 16 is requested to read a predetermined registered file by using the “file read” component 507 (step S34). In this example, the registered files are the files of the catalogs A, B, and C. These files are sequentially read out and requested. Next, the “file print instruction” component 502 requests the command processing / drawing unit 13 to draw the file data (step S35), and the “print start” component 510 requests the print control unit 14 to execute printing (step S35). S36).

The processes in steps S34 to S36 are repeated until all the registered files (the catalog A, B, and C files) are printed (NO in step S37 and return to step S34). When all files are printed (step S37, YES), for example, the process returns to step S31.
When individual printing is requested, the following processing is performed. In the following description, only the use of parts will be described without mentioning the requests to the operation panel control unit 11 and the like as described above.
First, the “display” component 500 is used to display the individual menu 40 of FIG. 2 (step S38). Subsequently, the selection button is read using the “input” component 501 (step S39), and the content (designated catalog) of the selection button is determined. Then, using the “file read” component 507, the specified catalog file is read (step S40). Next, the data of the specified catalog is drawn using the “file print instruction” component 502 (step S41), and printing is executed using the “print start” component 510 (step S42). .

Here, as already briefly described, among the processes in steps S31 to S42, processes other than steps S33 and S37, that is, processes using arbitrary components are not necessarily executed. That is, when executing the processes of the above steps S31, S32, S34 to S36, and S38 to S42, the process of FIG. 7 is executed, respectively, unless both the determinations of steps S52 and S53 described later are YES. The use of the parts of the step is not permitted, and the processing of the step is not substantially performed.
Hereinafter, the process of FIG. 7 will be described.

FIG. 7 shows a common flow executed when executing a process for using an arbitrary component. Only when it is determined that the use of the component is permitted, the process using the component is executed. Here, it is assumed that the processing function of FIG. 7 is incorporated in each component so that the processing of FIG. 7 is executed only when called from app 20 for each component, but the present invention is not limited to this example. For example, the app control unit 17 uses and executes a part only when it determines that it is permitted after executing the processes of steps S51, S52, and S53 for each use and execution of each part (step S54). May be performed.
In FIG. 7, the component that executes this process first requests and acquires the registrant authority level and the executor authority level passed during the app execution as arguments (arguments).

Further, the risk level of the part is determined (step S51). For example, in the process of FIG. 7 in the process of step S31, since the component is the “display” component 500, the risk level of the “display” component 500 is determined. Information necessary for determining the risk level may be stored in advance for each component (not limited to this example). For example, when the risk level is determined and registered in advance for each part, it may be referred to.
However, the risk level of parts such as the “file write” part 506 and the “file read” part 507 may be determined depending on the file to be accessed. Even in such a case, for example, if the risk level is set and registered for each file (or each storage location (folder, etc.)) handled in each part, the risk level is determined by referring to this. it can. Alternatively, the type of data specified by the argument (argument) (or the data storage location (folder or the like)) may be determined, and the risk level value may be determined based on this.

Alternatively, a risk level value is registered for each combination of each file (or storage location) and each part that can call the file, and the risk level value is determined by referring to this. May be.
For example, the “display” component 500 and the “input” component 501 have a fixed device, and the display contents to be set and the input values to be read are local contents of the app. It can be 1 mag. However, in the case of the “file read” component 507, if the file is in the local area (directory) of the app, the degree of danger is low, and it can be determined, for example, level 1 or the like. The degree changes.
As described above, the risk level is not necessarily determined by the component itself, but may be determined by the component itself and the usage method (access destination, etc.) of the component. The processing can also be said to be, for example, “determine the risk level corresponding to the part execution (part use)”.

The risk level determined in step S51 is compared with the registrant authority level and the executor authority level passed as arguments (arguments) as described above. Then, when both the registrant authority level and the executor authority level are higher than the risk level, the processing of the component is executed (processing using the component is permitted). (Step S54). That is, if “registrant authority level> risk level” (step S52, YES) and “executor authority level> risk level” (step S53, YES), the part can be executed. (Step S54).
On the other hand, if either the registrant authority level or the executor authority level is below the risk level of the part, the use of the part by the app 20 is not permitted. That is, if “registrant authority level ≦ risk level” (step S52, NO) or “executor authority level ≦ risk level” (step S53, NO), the execution / use of the part is Not permitted, for example, “authority error” is returned. In this case, the determination result of “whether or not authority is abnormal” in step S17 in FIG. 3 is YES, and an error display or the like is performed (step S19).

For example, if both the registrant authority level and the executor authority level exceed the risk level, the app execution is continued (permitted) as no problem, and if either of them is higher, the app execution is interrupted. (Don't allow) to avoid danger.
In this case, the execution of the entire app 20 may be stopped, but only the processing related to the component having the “authority abnormality” may be interrupted (not permitted), and the processing related to other components may be continued. For example, if the app executor designates “batch printing” 31 in FIG. 2, if “authority error” is returned and the error display in step S 19 is performed (unlike FIG. 3), the process returns to step S 16. Then, if “individual printing” 32 is designated this time, control such as normal execution may be performed. However, for example, when step S52 is NO (especially when the registrant authority level is extremely low (eg, “0”)), it is considered that the app 20 itself has low reliability, so the execution of the entire app 20 is stopped. It is desirable to do.

As described above, at the time of executing app, the part can be executed only when both the registrant authority level and the executor authority level are higher than the risk level related to the parts used in app. Therefore, it is possible to prevent inappropriate data access, falsification, and leakage by the additional embedded software.
Moreover, since execution permission / denial is performed for each part, for example, when the authority level of the executor is relatively low, for example, processing of a part with a high risk level related to access to important information cannot be used. However, it can be used for processing parts with a low risk level.

Here, for example, it is assumed that the risk level can be set to a value of “0” or more. In the example of FIG. 4, the app authority 53 of the “guest” user is “0”. The “guest” user is a user who cannot be specified (for example, is not registered). Although not limited to this example, it is desirable to set the authority level (app authority 53) of the guest user related to the add-on software to be equal to or lower than the lowest risk level.
In this example, when the “guest” user is an app registrant and / or an app executor, step S52 or / and step S53 is always NO. In this way, for example, a guest user who is not registered as a user (and thus difficult to identify) can register any app 20 in the printing apparatus 1, but cannot execute this app 20, and security Can be maintained.
In addition, even if the user 20 registered by the guest user has inadvertently activated the app 20, step S52 is always NO, so that this app 20 is executed regardless of the executor authority level. Can not be maintained, security can be maintained.
Or, conversely, step S53 is always NO even when the guest user starts app20 registered by the registered user and tries to obtain some information. This app 20 cannot be executed (regardless of whether it is high), and security can be maintained.

If either step S52 or S53 is YES, the control in step S54 is executed (permission / use of the part is permitted). If the registrant authority level is high (executor authority level) Regardless of whether the executor is a guest user, for example, even if the component execution content is reading important information (and therefore the risk level is high), it may be permitted. On the other hand, according to the process of FIG. 7, inappropriate data access by such add-on software can be prevented, thereby preventing data tampering and leakage.
As for users who have been registered, generally, general users have a relatively low app authority 53, and administrators or the like have a relatively high app authority 53. Thus, for example, with regard to app20 accompanied by component execution such as reading of information whose component execution contents are important (thus, the risk level is high), the execution is performed only when both the registrant and the executor are administrators. Can be allowed. In other words, for example, even if the executor is a general user, a situation in which execution is permitted if the registrant is an administrator can be prevented from occurring, which helps to enhance security.

On the other hand, if the app 20 has a low risk level (app that only uses components with a low risk level), it can be operated (registered and executed) by a general user without bothering the administrator.
Alternatively, although the use of parts with a low risk level is basically used, but with the execution of app 20 in which the use of parts with a high risk level is mixed, high-risk part processing exceeding the authority level of general users is performed. It is possible to create a system with high operability, such as disabling its execution only when it is performed.
As described above, the printing apparatus 1 of the present example has the following characteristics.
First, the printing apparatus 1 of this example is a printing apparatus that can execute main body software 10 that is a main body of control software and additional embedded software (app 20 or the like) that is added to the printing apparatus 1 in an arbitrary processing function. In other words, this is an additional embedded software processing apparatus that has a control software main body and can execute additional embedded software that realizes an arbitrary processing function using various components used in the control software main body.

The printing apparatus 1 includes a function unit for registering any additional embedded software as a processing function when registering the additional embedded software, and a function unit for identifying a user (registrant) who registered the additional embedded software, And a function unit that acquires the authority level of the registrant from the authority information (table 50 and the like), and a function unit that stores the acquired authority level (registrant authority level) and the additional embedded software in association with each other.
In addition, the printing apparatus 1 includes a function unit that selects and designates execution of arbitrary additional embedded software among the registered additional embedded software, as a processing function when the registered additional embedded software is executed, A functional unit that identifies the specified user (executor), a functional unit that acquires the authority level of the executor from the authority information, and the authority level of the registrant associated with the additional software that has been selected and specified, A function unit that activates the additional embedded software together with the authority level of the executor. Furthermore, for each of various parts to be called from the additional embedded software, a function unit for determining the risk level according to the part itself and the processing target, the authority levels of the registrant and the executor, and the determined risk And a function unit that determines whether or not to permit the execution of each component based on the level.

Note that the various functional units described above are realized by, for example, a CPU (not shown) of the printing apparatus 1 executing an application program stored in advance in a storage unit (not shown).
According to the printing apparatus 1, for example, the above-described effects can be obtained, but the following effects are also obtained (partly overlapping).
・ Depending on the setting of authority, additional embedded software in which a guest user who is an unregistered user, etc., becomes a registrant or executor can always be prevented from being executed. Only registered users whose names are specified are available. As a result, the user name at the time of introduction (registration) or execution of the additional embedded software can be specified and recorded in the log.
・ In addition, since low-privileged users cannot install or execute high-level additional embedded software, inappropriate information access, falsification, leakage, etc. can be prevented. For example, the “authority information change” component 505 is a program component that can change the user authority. If the user authority is altered by this, a serious problem occurs. Therefore, by setting a high risk level for such program parts, tampering and the like can be prevented.
Furthermore, if the app has a low risk level, a low-privileged user can introduce and execute it without bothering a high-level administrator or the like.
As described above, in the additional embedded software processing device such as a printing device capable of executing the control software main body and the additional embedded software to be added to the control software, the trouble associated with the registration and execution of the additional embedded software is reduced. By minimizing it, it is possible to prevent improper data access, falsification, and leakage by the additional embedded software. In the description of the above embodiment, the description has been given by taking the printing apparatus as an example of the additional embedded software processing apparatus. However, the present invention is not limited to this, and the user can arbitrarily add the additional embedded software. The present invention can be similarly applied to any additional embedded software processing device such as a document processing device, a multifunction device, an information processing device, a video processing device, and an image forming device that can be installed. Of course.

(Appendix 1)
A software component storage unit for storing a plurality of software components including a program for executing functional processing;
An additional embedded software registration unit for registering additional embedded software including a program for executing a combination of at least two or more of the software components;
A user authority storage unit that stores in advance the execution authority level of the additional embedded software for each user;
An executor authority level that identifies the user and obtains the authority level for the user from the user authority storage unit when the user tries to execute the additional embedded software registered by the additional embedded software registration unit An acquisition unit;
A risk level determination unit that determines a risk level corresponding to the execution of the software component for each of the software components processed in accordance with the execution of the additional embedded software;
Whether to permit execution of the software component based on the authority level acquired by the executor authority level acquisition unit corresponding to the additional embedded software to be executed and the risk level for each software component A software component execution control unit for determining whether or not,
An additional embedded software processing device.

(Appendix 2)
The user authority storage unit stores a registrant authority level for a registrant who registers the additional embedded software via the software registration unit and an executor authority level for an executor who executes the additional embedded software. The additional embedded software according to claim 1, wherein the authority level determined by the software component execution control unit includes the registrant authority level of the additional embedded software and the executor authority level. Processing equipment.

(Appendix 3)
The software component execution control unit permits execution of the software component when both the registrant authority level and the performer authority level are higher than the risk level of an arbitrary software component. The additional embedded software processing device according to appendix 2.

(Appendix 4)
The additional embedded software processing apparatus according to appendix 1, 2, or 3, wherein the risk level is stored in advance in a risk registration storage unit for registering a risk level for each software component.

(Appendix 5)
The additional embedded software processing apparatus according to appendix 1, 2, or 3, wherein the risk level is set according to a file accessed by execution of the software component or a storage location of the file.

(Appendix 6)
A process for storing a plurality of software components including a program for executing a function process;
A process of registering additional embedded software from outside that includes a program for executing a combination of at least two of the software components;
Processing for storing the execution authority level of the additional embedded software in advance for each user;
When the user tries to execute the additional embedded software registered by the additional embedded software registration unit, the process of identifying the user and obtaining the authority level for the user from the user authority storage unit;
A process for determining a risk level corresponding to the execution of the software component for each software component processed in accordance with the execution of the additional embedded software;
Whether to permit execution of the software component based on the authority level acquired by the executor authority level acquisition unit corresponding to the additional embedded software to be executed and the risk level for each software component Processing to determine whether or not,
An additional embedded software execution control method characterized by executing

1 Printing device (additional embedded software processing device)
2 Controller 3 Print engine 4 PC (PC)
DESCRIPTION OF SYMBOLS 10 Main body software 11 Operation panel control part 12 Engine control part 13 Command processing / drawing part 14 Print control part 15 User authority management part 16 Disk control part 17 App control part 20 app
30 Print menu screen 31 “Batch print” button 32 “Individual print” button 33 “Exit” button 40 Individual selection menu screen 50 User authority table 51 User name 52 Print authority 53 App authority

Claims (6)

A software component storage unit for storing a plurality of software components including a program for executing functional processing;
An additional embedded software registration unit for registering additional embedded software including a program for executing a combination of at least two or more of the software components;
A user authority storage unit for storing the authority level of the additional embedded software in advance for each user;
An executor authority level that identifies the user and obtains the authority level for the user from the user authority storage unit when the user tries to execute the additional embedded software registered by the additional embedded software registration unit An acquisition unit;
A risk level determination unit that determines a risk level corresponding to the execution of the additional embedded software for each of the software components processed in accordance with the execution of the additional embedded software;
Based on the authority level acquired by the executor authority level acquisition unit corresponding to the additional embedded software to be executed, and the risk level for each software component determined by the risk level determination unit A software component execution control unit that determines whether to allow execution of the software component;
An additional embedded software processing device. Wherein the software component storage unit, the additional embedded software the registering unit via a registrant who has registered the said additional embedded software privilege level is stored as the registered authority level, the software component execution control unit determines the privilege level of the previous SL registration authority level and additional embedded software processing apparatus according to claim 1, characterized in that it comprises a said execution rights levels.   The software component execution control unit permits execution of the software component when both the registrant authority level and the performer authority level are higher than the risk level of an arbitrary software component. The additional embedded software processing apparatus according to claim 2.   4. The additional embedded software processing apparatus according to claim 1, wherein the risk level is stored in advance in a risk registration storage unit that registers a risk level for each software component.   4. The risk level of the software component having a file access function is set according to a file accessed by execution of the software component or a storage location of the file. Additional embedded software processing device described in 1. A software component storage unit for storing a plurality of software components including a program for executing functional processing;
An additional embedded software registration unit for registering additional embedded software including a program for executing a combination of at least two or more of the software components;
A user authority storage unit for storing the authority level of the additional embedded software in advance for each user;
An executor authority level that identifies the user and obtains the authority level for the user from the user authority storage unit when the user tries to execute the additional embedded software registered by the additional embedded software registration unit An acquisition unit;
A risk level determination unit that determines a risk level corresponding to the execution of the additional embedded software for each of the software components processed in accordance with the execution of the additional embedded software;
Based on the authority level acquired by the executor authority level acquisition unit corresponding to the additional embedded software to be executed, and the risk level for each software component determined by the risk level determination unit A software component execution control unit that determines whether to allow execution of the software component;
A printing apparatus comprising an additional embedded software processing apparatus.