Patent Description:
In an image forming apparatus and an information processing apparatus, it is possible to add a function afterward by adding on a plugin application to a software framework in each apparatus. By adopting such a method, it becomes possible to add a function to each apparatus without modifying an existing source code in the apparatus as little as possible. When using the added function, a request source module for the function designates a plugin application corresponding to the function, and then notifies the software framework of an execution request. The software framework executes the designated plugin application in accordance with the request.

<CIT> proposes a technique of displaying a Web page on a UI of an image processing apparatus to which a plugin application is added on, executing a script linked with a corresponding portion of the Web page when a user selects the portion, and calling a corresponding plugin application.

However, the above-described related art has a problem to be described below. When using the added function, the request source module for the function needs to select an appropriate plugin application. In the above-described related art, for example, the request source module for the function inquires of another information processing apparatus a specific plugin application to be used, and then selects the plugin application in accordance with an answer for it. At this time, if the information processing apparatus to be inquired does not exist, the request source module for the function itself needs to determine and select the specific plugin application to be used. If the request source module for the function selects a wrong plugin, it may execute an unintended process. In addition, some constraint acts on a screen arrangement or specification while designing and developing a product by conducting registration with a plugin application or the like being linked with a selectable (operable) portion of a screen or the like displayed in a Web page on the UI. Consequently, the degree of freedom in design may be decreased considerably. <CIT>, <CIT>, and <CIT> disclose further image processing apparatuses capable of adding a function to be provided by installing a plugin application.

The present invention enables realization of a mechanism in which a request source module for a function added to an apparatus afterward selects an appropriate plugin application preferably when using the function.

According to a first aspect of the present invention there is provided an image processing apparatus according to claims <NUM>-<NUM>.

According to a second aspect of the present invention there is provided a method of an image processing apparatus according to claim <NUM>.

According to a third aspect of the present invention there is provided a program according to claim <NUM>.

Further features of the present invention will be apparent from the following description of exemplary embodiments with reference to the attached drawings.

Preferred embodiments of the present invention will now be described in detail with reference to the drawings. It should be noted that the relative arrangement of the components, the numerical expressions and numerical values set forth in these embodiments do not limit the scope of the present invention unless it is specifically stated otherwise. It should further be noted that what is described as the first and second embodiments are not according to the invention and are present for illustration purposes only.

The first embodiment of the present invention will be described below. First, an arrangement example of an image forming system according to this embodiment will be described with reference to <FIG> is a view showing an example of the arrangement of the image forming system. The image forming system includes image forming apparatuses <NUM> and <NUM> each serving as an example of an image processing apparatus, information processing terminals <NUM> and <NUM>, and a server <NUM>. The image forming apparatuses <NUM> and <NUM>, the information processing terminals <NUM> and <NUM>, and the server <NUM> are connected to and communicated with each other via a network <NUM>. The network <NUM> is a network such as a LAN (Local Area Network) or the Internet through which the apparatuses in the image forming system can communicate with each other.

<FIG> illustrates an example in which the two image forming apparatuses <NUM> and <NUM> are arranged. However, an arbitrary number (one or more) of image forming apparatuses can be arranged in the image forming system. In this embodiment, the image forming apparatuses <NUM> and <NUM> are MFPs (Multifunction Peripherals), but can be any one of, for example, an MFP, a printing apparatus, a copying machine, and a facsimile apparatus. In the following description, it is assumed that the image forming apparatuses <NUM> and <NUM> have the same arrangement, and a detailed description of the image forming apparatus <NUM> will be omitted.

The image forming apparatus <NUM> includes a printer and a scanner, and can, for example, receive a print request (print data) from the information processing terminals <NUM> and <NUM> and cause the printer to perform printing. The image forming apparatus <NUM> can also cause the scanner to read an original image and generate image data. The image forming apparatus <NUM> can cause the printer to perform printing based on the image data generated by the scanner and can store print data received from the information processing terminals <NUM> and <NUM>. In addition, the image forming apparatus <NUM> can perform transmission of the image data generated by the scanner to the information processing terminals <NUM> and <NUM>, image processing using the server <NUM>, and printing of a document stored in the server <NUM>. The image forming apparatus <NUM> further provides various kinds of services using the printer and scanner, and can be arranged such that a new service (function) can be added. More specifically, the addition of the new service can be implemented by installing an additional plugin application in the image forming apparatus <NUM>.

Next, an example of the hardware arrangement of the image forming apparatus <NUM> will be described with reference to <FIG>. The image forming apparatus <NUM> includes a controller <NUM>, a printer <NUM>, a scanner <NUM>, and an operation unit <NUM>. The controller <NUM> includes a CPU <NUM>, a RAM <NUM>, an HDD <NUM>, a network interface (I/F) <NUM>, a printer I/F <NUM>, a scanner I/F <NUM>, an operation unit I/F <NUM>, and an extension I/F <NUM>. The CPU <NUM> can exchange data with the RAM <NUM>, the HDD <NUM>, the network I/F <NUM>, the printer I/F <NUM>, the scanner I/F <NUM>, the operation unit I/F <NUM>, and the extension I/F <NUM>. In addition, the CPU <NUM> loads a program (instruction) read out from the HDD <NUM> in the RAM <NUM> and executes the program loaded in the RAM <NUM>.

Programs executable by the CPU <NUM>, setting values used in the image forming apparatus <NUM>, data associated with processing requested from a user, and the like can be stored in the HDD <NUM>. The RAM <NUM> is used to temporarily store the program read out from the HDD <NUM> by the CPU <NUM>. The RAM <NUM> is used to store various kinds of data necessary for executing the program. The network I/F <NUM> is an interface for communicating with other apparatuses in the image forming system via the network <NUM>. The network I/F <NUM> can notify the CPU <NUM> of reception of data and transmit the data on the RAM <NUM> to the network <NUM>.

The printer I/F <NUM> can transmit print data received from the CPU <NUM> to the printer <NUM> and notify the CPU <NUM> of the state of the printer <NUM> notified from the printer <NUM>. The scanner I/F <NUM> can transmit, to the scanner <NUM>, an image reading instruction received from the CPU <NUM> and transmit, to the CPU <NUM>, the image data received from the scanner <NUM>. The scanner I/F <NUM> can notify the CPU <NUM> of the state of the scanner <NUM> notified from the scanner <NUM>.

The operation unit I/F <NUM> can notify the CPU <NUM> of an instruction input on the operation unit <NUM> by the user and transmit, to the operation unit <NUM>, screen information of an operation screen which accepts a user operation. The extension I/F <NUM> is an interface capable of connecting an external apparatus to the image forming apparatus <NUM>. The extension I/F <NUM> is an interface in the form of, for example, USB (Universal Serial Bus). When an external storage device such as a USB memory is connected to the extension I/F <NUM>, the image forming apparatus <NUM> can read out the data stored in the external storage device and write the data to the external storage device.

The printer <NUM> can print, on a sheet, an image corresponding to the image data received from the printer I/F <NUM> and notify the printer I/F <NUM> of the state of the printer <NUM>. The scanner <NUM> can read an original image in accordance with an image reading instruction received from the scanner I/F <NUM> to generate image data, and transmit the generated image data to the scanner I/F <NUM>. In addition, the scanner <NUM> can notify the scanner I/F <NUM> of the state of the scanner <NUM>. The operation unit <NUM> is an interface for causing the user to perform operation for sending various kinds of instructions to the image forming apparatus <NUM>. For example, the operation unit <NUM> includes a display unit having a touch panel function, provides an operation screen to the user, and accepts an operation from the user via the operation screen.

Next, the outline of an image processing (information processing) system installed in the image forming apparatus <NUM> according to this embodiment will be described with reference to <FIG>. In this embodiment, the image processing system includes a platform module <NUM>, a native application <NUM>, an extension application <NUM>, a native module <NUM>, an image processing execution client <NUM>, an image processing execution server <NUM>, and extension processing plugins <NUM> to <NUM>.

The native application <NUM> or the extension application <NUM> (Java application) can request the platform module <NUM> to perform execution of desired image processing (information processing) in accordance with a user instruction. The native application <NUM> is described by a program language such as a C language and is the standard (preinstalled) application of the image forming apparatus <NUM>. The native application <NUM> includes, for example, a print application, a copy application, a scan application, and a transmission application. In order to update the native application <NUM>, the firmware of the image forming apparatus <NUM> must be updated. The extension application <NUM> is an application described by a program language such as a Java language. The extension application <NUM> is installed afterward in the image forming apparatus <NUM> to extend the function of the image forming apparatus <NUM>. For example, the extension application <NUM> is a login application for managing user login to the image forming apparatus <NUM>.

In the image forming apparatus <NUM>, one or more extension processing plugins can be operated on the platform module <NUM>. In this embodiment, the three extension processing plugins <NUM> to <NUM> are operated on the platform module <NUM>. The extension processing plugins <NUM> to <NUM> are installed afterward in the image forming apparatus <NUM> to extend the functions of the image forming apparatus <NUM> like the extension application <NUM>. To update the function of the extension processing plugin, the plugin is simply updated, and the firmware of the image forming apparatus <NUM> need not be updated.

In this embodiment, the extension processing plugin <NUM> is an extension processing plugin connected to a library described by the Java language in the image forming apparatus <NUM> to execute processing. The extension processing plugin <NUM> is an extension processing plugin connected to an external server such as a cloud server to execute processing. The extension processing plugin <NUM> is an extension processing plugin connected to the native module <NUM> described by the C language to execute processing.

The extension processing plugin <NUM> is connected to the native module <NUM> via the image processing execution client <NUM> and the image processing execution server <NUM>. The native module <NUM> is preinstalled in the image forming apparatus <NUM> like the native application <NUM>. In order to update the native module <NUM>, the firmware of the image forming apparatus <NUM> needs to be updated like the native application <NUM>. According to this embodiment, the native module <NUM> is a module which provides OCR processing. Note that the extension processing plugins <NUM> to <NUM> are merely examples, and the connection destination and processing contents of the extension processing plugin are not limited to the above connection destinations and processing contents.

The platform module <NUM> can accept an image processing execution request from the native application <NUM> or the extension application <NUM>. For example, the platform module <NUM> accepts the execution request of the OCR processing for extracting a character image from the scanned image from the scan application. Upon accepting the image processing execution request, the platform module <NUM> selects an extension processing plugin for executing image processing in accordance with an execution request out of the extension processing plugins <NUM> to <NUM> and instructs to cause the selected extension processing plugin to execute image processing. For example, the platform module <NUM> decides the extension processing plugin to be used, based on the type and contents (whether promptness is required, the degree of processing load, and the like) of the image processing, the execution of which is requested. The platform module <NUM> obtains the execution result of the requested image processing from the used extension processing plugin. The platform module <NUM> outputs the obtained execution result as a response to the execution request to the application of the transmission source of the execution request.

Note that each element shown in <FIG> has the following correspondence relationship with each element (to be described below) shown in <FIG>. The platform module <NUM> corresponds to a connection library <NUM>. The native application <NUM> corresponds to device control libraries <NUM>. The extension application <NUM> corresponds to a single function plugin application <NUM>. The extension processing plugins <NUM> to <NUM> correspond to an image processing plugin application <NUM>. The native module <NUM> corresponds to a native module <NUM>. The image processing execution client <NUM> corresponds to a native client <NUM>. The image processing execution server <NUM> corresponds to a native server <NUM>.

Next, an example of the software arrangement of the image forming apparatus <NUM> will be described with reference to <FIG>. The software arrangement of the image forming apparatus <NUM> is implemented by, for example, the programs stored in the HDD <NUM>. The software arrangement shown in <FIG> includes a hierarchical structure formed from a lowermost layer including an operating system <NUM>, an uppermost layer corresponding to Java® language execution environment <NUM>, and an intermediate layer between the lowermost and uppermost layers. This hierarchical structure has a relationship in which excluding some exceptions, a service provided by a lower layer can be used by an upper layer. Note that the exceptions indicate that each device control library <NUM> can use, via an image processing controller <NUM>, the image processing plugin application <NUM> included in the uppermost layer, as will be described later.

The lowermost layer is a layer including the operating system <NUM> to perform program execution management, memory management, and the like. A printer control driver <NUM>, a scanner control driver <NUM>, and a network I/F control driver <NUM> are embedded in the operating system <NUM>. The printer control driver <NUM>, the scanner control driver <NUM>, and the network I/F control driver <NUM> can function to cooperate with each other. The printer control driver <NUM> is software for controlling the printer <NUM> via the printer I/F <NUM>. The scanner control driver <NUM> is software for controlling the scanner <NUM> via the scanner I/F <NUM>. The network I/F control driver <NUM> is software for controlling the network I/F <NUM>.

The intermediate layer higher than the lowermost layer includes the device control libraries <NUM> and the image processing controller <NUM>. In this embodiment, the programs of the device control libraries <NUM> and the image processing controller <NUM> can be described by a compiler language such as the C language or C++ language and stored in the HDD <NUM> in the form of an object file which can be directly executed by the CPU <NUM>.

The uppermost layer is an application layer including an application operated in the Java language execution environment <NUM>. The uppermost layer includes plugin applications <NUM> and the device control applications <NUM> and further includes the native client <NUM>, the connection library <NUM>, and an external client <NUM>. Each application of the uppermost layer is operated using an API provided by a corresponding one of the device control libraries <NUM> or the connection library <NUM>, thereby providing various kinds of functions. Note that the functions of the device control applications <NUM> can be extended by updating the firmware of the image forming apparatus <NUM>.

In this embodiment, the programs of the plugin applications <NUM> and the device control applications <NUM> can be described by the Java language and stored in the HDD <NUM> in a Java byte code format which can be interpreted by a Java virtual machine. For this reason, the CPU <NUM> executes the program of the Java virtual machine, reads out the program in the Java byte code format from the HDD <NUM>, and causes the Java virtual machine to execute the program, thereby implementing processing by each application of the uppermost layer.

As described above, one of the reasons for using the programming language such as the Java language is descriptive facilitation of the program. Since the management of the memory area is automatically performed in the Java, a developer need not manage the memory area. For this reason, the developer's labor at the time of describing a program can be reduced, and it is expected that the developing efficiency can be improved.

Next, the device control libraries <NUM> will be described in more detail. The device control libraries <NUM> are statically or dynamically linked to the single function plugin application <NUM> or a corresponding one of the device control applications <NUM> to be described later. Each device control library <NUM> uses the operating system <NUM> of the lowermost layer based on an instruction by each application of the uppermost layer. In addition, each device control library <NUM> can request the execution of the image processing for a native connection library <NUM>. As an example, the device control libraries <NUM> are formed from a print library <NUM>, a copy library <NUM>, a scan storage library <NUM>, and a scan transmission library <NUM>.

The print library <NUM> provides an API (Application Programming Interface) for controlling a print job using the function of the printer control driver <NUM>. The print job indicates a series of processes of performing printing at the printer <NUM> based on print data stored in the HDD <NUM> or print data received from an external apparatus (the information processing terminal <NUM> or <NUM>, or the like) via the network I/F <NUM>. The copy library <NUM> provides an API for controlling a copy job using the functions of the scanner control driver <NUM> and the printer control driver <NUM>. The copy job is a series of processes for scanning an original image at the scanner <NUM> and printing at the printer <NUM> based on the obtained image data.

The scan storage library <NUM> provides an API for controlling a scan storage job using the function of the scanner control driver <NUM>. The scan storage job is a series of processes of performing scanning of the original image at the scanner <NUM>, conversion of the obtained image data into the print data or data in a general format, and storage of data in the HDD <NUM> or an external storage device such as a USB memory connected to the extension I/F <NUM>. Note that the general format is a data format such as PDF (Portable Document Format) or JPEG (Joint Photographic Experts Group).

The scan transmission library <NUM> provides an API for controlling a scan transmission job using the functions of the scanner control driver <NUM> and the network I/F control driver <NUM>. The scan transmission job is a series of processes for performing scanning of the original image at the scanner <NUM>, conversion of the obtained image data into data in a general format, and transmission of the data to an external apparatus via the network I/F <NUM>. In the scan transmission job, the data is transmitted to, for example, the file server such as the server <NUM> via the network I/F <NUM> or transmitted to an external apparatus such as the information processing terminal <NUM> or <NUM> by email.

Next, the image processing controller <NUM> will be described in more detail. The image processing controller <NUM> includes the native connection library <NUM>, the native server <NUM>, and the native module <NUM>. Upon receiving an image processing execution request from the device control libraries <NUM>, the native connection library <NUM> transfers the request contents to the connection library <NUM>. Upon receiving a request from the application operating in the Java language execution environment <NUM> (to be described later), the native server <NUM> provides the function of executing the native module <NUM>. The native module <NUM> is software capable of executing various kinds of image processing.

The native server <NUM> and the native module <NUM> are executed on a native control process <NUM>, as shown in <FIG>. The native control process <NUM> is a program execution unit having a logical memory space separated from a logical memory space of software other than the native server <NUM> and the native module <NUM>. Note that this memory space separation can be implemented by another method such as a method using a process mechanism of a general OS (Operating System).

According to this embodiment, as described above, the logical memory space of the native control process <NUM> is independent of the logical memory space of the other software. For this reason, even if an error occurs in the memory operation on the native control process <NUM>, such an error can be prevented from influencing the logical memory space of the application on the side for requesting the execution of the image processing on the native server <NUM>. That is, the error in the operation of the application on the side for requesting the execution of the image processing on the native server <NUM> can be prevented.

Next, the device control applications <NUM> will be described in more detail. As an example, the device control applications <NUM> include a print application <NUM>, a copy application <NUM>, a scan storage application <NUM>, and a scan transmission application <NUM>. The device control applications <NUM> are resident applications in the image forming apparatus <NUM>.

The print application <NUM>, the copy application <NUM>, the scan storage application <NUM>, and the scan transmission application <NUM> have screen information <NUM>, screen information <NUM>, screen information <NUM>, and screen information <NUM>, respectively. The CPU <NUM> can display the corresponding operation screen on the operation unit <NUM> via the operation unit I/F <NUM> based on the screen information <NUM>, the screen information <NUM>, the screen information <NUM>, and the screen information <NUM>. The CPU <NUM> can accept an instruction from the user via the displayed operation screen.

Upon detecting that the user operates operation unit <NUM> to change the settings of the device control applications <NUM>, the CPU <NUM> writes the change contents in the HDD <NUM>. Upon detecting that the user operates the operation unit <NUM> to request the job execution, the CPU <NUM> (each device control application <NUM>) calls the API of a corresponding one of the device control libraries <NUM>, thereby starting execution of the job. In addition, the CPU <NUM> (each device control application <NUM>) can request the execution of the image processing to the connection library <NUM>.

For example, the print application <NUM> calls the API of the print library <NUM> to execute a print job. The copy application <NUM> calls the API of the copy library <NUM> to execute a copy job. The scan storage application <NUM> calls the API of the scan storage library <NUM> to execute a scan storage job. The scan transmission application <NUM> calls the API of the scan transmission library <NUM> to execute a scan transmission job.

Next, the plugin applications <NUM> will be described in more detail. Different from the device control applications <NUM> as the resident applications, the plugin applications <NUM> are applications which can be installed or uninstalled as a plugin to or from the image forming apparatus <NUM>. The plugin applications <NUM> are installed in the image forming apparatus <NUM> by using a remote UI (User Interface) or the like. Note that in the external apparatus such as the information processing terminal <NUM> or <NUM>, the remote UI is a mechanism for accessing the image forming apparatus <NUM> from a Web browser and allowing confirmation of a situation of the image forming apparatus <NUM>, an operation of the print job, and various kinds of settings.

The plugin applications <NUM> include the single function plugin application <NUM> and the image processing plugin application <NUM>. In the plugin applications <NUM> (the single function plugin application <NUM> and the image processing plugin application <NUM>), programs necessary for the respective operations are packaged. The plugin applications <NUM> can be individually activated or stopped.

A series of operations from installation to the activation, stop and uninstallation of the plugin applications <NUM> will be described below. When detecting the installation of the plugin applications <NUM> using the remote UI or the like, the CPU <NUM> stores the information of the plugin applications in the HDD <NUM>. Next, upon detecting the activation instruction to the plugin applications <NUM>, the CPU <NUM> instructs the activation of the plugin applications. While the plugin applications <NUM> are activated, the functions of the plugin applications can be provided.

After that, when the CPU <NUM> detects a stop instruction to the plugin applications <NUM>, the CPU <NUM> instructs the stop of the plugin applications <NUM>. In addition, when the CPU <NUM> detects an uninstallation instruction to the plugin applications <NUM>, the information of the plugin applications <NUM> is deleted from the HDD <NUM>, thereby uninstalling the plugin applications. Note that each instruction detected by the CPU <NUM> can be performed from, for example, the remote UI or the operation unit <NUM>. However, an instruction can be performed by a method other than the above method.

Next, the single function plugin application <NUM> will be described in more detail. The single function plugin application <NUM> has screen information <NUM>. Based on the screen information <NUM>, the CPU <NUM> can display the corresponding operation screen on the operation unit <NUM> via the operation unit I/F <NUM>. In addition, the CPU <NUM> can accept an instruction from the user via the displayed operation screen.

The single function plugin application <NUM> can provide a function or screen different from the device control applications <NUM> to the user by calling the API provided by the device control libraries <NUM>. The single function plugin application <NUM> can provide a plurality of functions by the device control libraries <NUM> in combination. For example, the single function plugin application <NUM> can provide the function of copying a given image and transmitting image data obtained by scanning to a specific destination in a destination database which holds this plugin application itself.

Note that the single function plugin application <NUM> need not have the image processing function. In this case, no setting is performed for the image processing. When the device control libraries <NUM> receive, from the single function plugin application <NUM>, print data or image data converted into a general format, the device control libraries <NUM> instruct control of necessary processing to the operating system <NUM>, thereby executing the job.

Next, the image processing plugin application <NUM> will be described in more detail. The image processing plugin application <NUM> is an application for providing the specific image processing. Note that the image processing plugin application <NUM> may be formed from a plurality of applications for executing different image processing operations. For example, a plurality of applications capable of executing, for example, image format conversion, skew correction, form recognition, and OCR processing of an input image may be installed in the image forming apparatus <NUM> as the image processing plugin application <NUM>. Note that it is desirable that the image processing plugin application <NUM> holds, as image processing information indicating image processing executable in the application, the name of the image processing (image processing name) when installed additionally. This makes it possible to preferably determine whether image processing corresponding to an image processing name inquired in step S603 of <FIG> (to be described later) is executable.

The image processing plugin application <NUM> can accept an image processing request (an image processing execution request) from the single function plugin application <NUM> or the device control applications <NUM> via the connection library <NUM>. In addition, the image processing plugin application <NUM> can also accept an image processing request from the device control libraries <NUM> via the native connection library <NUM> and the connection library <NUM>.

The image processing plugin application <NUM> executes image processing in accordance with an accepted image processing request. The image processing request can include image data and processing parameters of a processing target. The processing parameters include parameters related to an image processing name and image processing (to be described later). In addition, the image processing plugin application <NUM> can use the image processing function of the native client <NUM> based on the image processing request, as needed. Note that the image processing plugin application <NUM> need not have its image processing function. Even if the image processing plugin application <NUM> does not have the image processing function, the image processing plugin application <NUM> can use the image processing function of the native module <NUM> by using the native client <NUM>.

One of the reasons for causing the image processing plugin application <NUM> to use the native module <NUM> is a high processing speed in image processing. More specifically, when performing image processing, execution of complicated numerical arithmetic operations in a large amount is required, and a large-capacity memory in the course of processing is required. In this case, a higher processing speed can be expected by using not a processing system using a programming language for performing processing via a virtual machine like Java, but a processing system using a compiler language for generating an object file directly executed by the CPU.

Furthermore, the image processing plugin application <NUM> can also transmit an input image and an image processing request to an external apparatus such as the server (external apparatus) <NUM> by using the external client <NUM>, and request the execution of image processing by an external image processing client. This makes it possible to execute image processing which cannot be executed by the image forming apparatus <NUM> or execute high-speed processing using a large-capacity memory.

Next, an arrangement example of a server according this embodiment will be described with reference to <FIG>. The server <NUM> includes a CPU <NUM>, a RAM <NUM>, an HDD <NUM>, and a network I/F <NUM>. The CPU <NUM> can exchange data with the RAM <NUM>, the HDD <NUM>, and the network I/F <NUM>. In addition, the CPU <NUM> loads a program (instruction) read out from the HDD <NUM> in the RAM <NUM> and executes the program loaded in the RAM <NUM>.

Programs executable by the CPU <NUM>, setting values used in the server <NUM>, data associated with processing requested from the user, and the like can be stored in the HDD <NUM>. The RAM <NUM> is used to temporarily store the program read out from the HDD <NUM> by the CPU <NUM>. The RAM <NUM> can store various kinds of data necessary for executing the program. The network I/F <NUM> is an interface for performing network communication with other apparatuses that exist on a network. The network I/F <NUM> can notify the CPU <NUM> of reception of data and transmit the data on the RAM <NUM> to the network <NUM>.

Next, an example of a software structure processed by the CPU <NUM> will be described with reference to <FIG>. Software that has a structure shown in <FIG> is implemented by, for example, the programs stored in the HDD <NUM> of the server <NUM>. The server <NUM> includes, as a software arrangement, a module <NUM> and a communication library <NUM>. Note that there is no intention to limit the software arrangement of the server in the present invention to only the above-described two components, and another module and the like may be included.

The module <NUM> receives an input image and an image processing request transmitted from the communication library <NUM>, and executes image processing on the input image in accordance with the request. Then, the module <NUM> makes a notification of processed image data via the communication library <NUM>. The communication library <NUM> is a library that provides an API for executing communication processing with another device existing on the network <NUM> such as the image forming apparatus <NUM>. The communication library <NUM> receives an input image and an image processing request transmitted from the image forming apparatus <NUM>, and transfers them to the module <NUM>. Furthermore, the communication library <NUM> transmits, to the image forming apparatus <NUM>, processed image data generated by the module <NUM>.

Next, a processing procedure when the connection library <NUM> calls the image processing plugin application <NUM> will be described with reference to <FIG>. Processing to be described below is implemented by, for example, loading programs stored in the HDD <NUM> in the RAM <NUM> and causing the CPU <NUM> to execute the programs.

First, in step S601, the connection library <NUM> functions as an acceptance unit and accepts an image processing execution request from the single function plugin application <NUM> or the device control applications <NUM>. Note that the connection library <NUM> receives, as image processing information corresponding to image processing, the execution of which is requested, an image processing name and designation of a parameter. For example, the image processing name (ImagingName) may be a character string such as "OCR". In addition, a parameter related to the image processing like "language: Japanese" is designated as the parameter.

Next, in step S602, the connection library <NUM> acquires the image processing name designated in step S601 from the accepted request. Subsequently, in step S603, the connection library <NUM> designates an image processing name for all the installed image processing plugin applications <NUM> and makes an inquiry about whether image processing corresponding to it is executable. Note that each image processing plugin application <NUM> determines whether it can execute image processing corresponding to the designated image processing name and responds to the connection library <NUM> with that result. Thus, according to this embodiment, it is possible to preferably select a plugin application suitable for requested image processing from installed plugin applications by using an image processing name as a search key. That is, the connection library <NUM> need not grasp plugins corresponding to various kinds of image processing, and can select an appropriate plugin application by extracting an image processing name from the request and inquiring of the respective plugin applications. Consequently, for example, registration processing such as linking an installed plugin application with each image processing button on a menu screen is not needed, making it possible to improve the degree of freedom in development design in a product and omit extra processing as well.

Next, in step S604, the connection library <NUM> determines, based on each response, whether the image processing plugin application <NUM> capable of executing image processing corresponding to the image processing name as the image processing information exists. If the image processing plugin application <NUM> exists, the process advances to step S605. If the image processing plugin application <NUM> does not exist, the process advances to step S606. For example, in the above-described example, if the image processing plugin application <NUM> corresponding to the image processing name "OCR" exists, the process advances to step S605. In step S605, the connection library <NUM> notifies the image processing plugin application <NUM> of an image processing execution instruction after notifying it of the parameter designated in step S601. On the other hand, in step S606, the connection library <NUM> notifies an image processing request source that the image processing plugin application <NUM> capable of executing image processing is not found for the device control applications <NUM> or each device control library <NUM>, thereby ending the processing. More specifically, the connection library <NUM> notifies the request source that a plugin application capable of executing predetermined image processing does not exist.

As described above, the image processing apparatus (image forming apparatus) according to this embodiment accepts a request to execute predetermined image processing and acquires an image processing name indicating a name of the predetermined image processing from the request. In addition, the image processing apparatus selects a plugin application capable of executing accepted predetermined image processing by using the acquired image processing name and instructs the execution of the processing. According to this embodiment, this eliminates the need to select a plugin directly by a request source module using an added image processing function, making it possible to use an appropriate plugin by simply designating an image processing name and reduce a risk of wrong selection of a plugin.

The present invention is not limited to the above-described embodiment, and various modifications can be made. For example, in step S603 described above, the connection library <NUM> inquires of each image processing plugin application <NUM> by using an image processing name whether image processing corresponding to the image processing name is executable. Instead of this arrangement, when each image processing plugin application <NUM> is installed, an image processing name of image processing executable by itself may be registered in linkage with the plugin application for the connection library <NUM>. This allows the connection library <NUM> to select an appropriate plugin based on information held by itself using an image processing name without inquiring of each image processing plugin application.

The second embodiment of the present invention will be described below. In the above-described first embodiment, the connection library <NUM> selects a plugin by designating an image processing name for the image processing plugin application <NUM> and making an inquiry about whether image processing corresponding to it is executable.

Only from the image processing name, however, the image processing plugin application <NUM> may not be selected correctly. A case in which "OCR" is designated as an image processing name will be considered here. As plugins that perform OCR processing, there exist a plugin that requests a process from a native module <NUM> in a device and a plugin that requests a process from a server <NUM> via a network <NUM>. The former is a plugin for performing a process for a language such as English an OCR dictionary thereof exists in the device. The latter is a plugin for performing a process for a language a dictionary thereof does not exist in the device. In such a case, there exist a plurality of plugins corresponding to an image processing name of "OCR". It is therefore impossible to select an image processing plugin application <NUM> correctly only from information of the image processing name.

To cope with this, in this embodiment, parameter information related to image processing is used in addition to an image processing name when selecting the image processing plugin application <NUM>. The parameter is formed by a pair of key and value, and a plurality of pairs may be designated for one image processing operation. In the above-described example, expressing the parameter in the form of "key: value", a term "language: English" is designated. Based on information of the image processing name "OCR", parameter, and "language: English", a connection library <NUM> can select the image processing plugin application <NUM> that executes OCR processing by using the native module <NUM>.

As another example, a case is also considered in which plugins to be used are switched by an "input image resolution" designated as a parameter. First, if "input image resolution: <NUM> DPI" is designated as a parameter, a plugin that requests a process from the native module <NUM> in the device is used. On the other hand, if "input image resolution: <NUM> DPI" is designated as a parameter, a plugin that requests a process from the server <NUM> is used. This is because the space of a RAM <NUM> needed for processing increases as an input resolution increases, and thus predetermined limitations are imposed on an input image resolution to be processed in an image forming apparatus <NUM>, and it is necessary to request a process from the server <NUM> if a predetermined input resolution is exceeded.

A processing procedure when the connection library <NUM> calls the image processing plugin application <NUM> in this embodiment will be described with reference to <FIG>. Processing to be described below is implemented by, for example, loading programs stored in an HDD <NUM> in a RAM <NUM> and causing a CPU <NUM> to execute the programs. Note that the system arrangement and the processing procedure of this embodiment are the same as those described in the first embodiment above, a description thereof will be omitted, and only different portions will be described. More specifically, steps S701, S704, S705, and S706 are the same as steps S601, S604, S605, and S606, and thus a description thereof will be omitted.

In step S702, the connection library <NUM> refers to an image processing name and parameter designated in step S701. Furthermore, in step S703, the connection library <NUM> designates an image processing name and a parameter for all the installed image processing plugin applications <NUM>, and makes an inquiry about whether image processing corresponding to them is executable.

As described above, according to this embodiment, it becomes possible to select the image processing plugin application <NUM> under a more detailed condition based on two kinds of information of the image processing name and the parameter. In addition, as described above, in step S703 above, the connection library <NUM> inquires of each image processing plugin application <NUM> by using an image processing name and a parameter whether image processing corresponding to the image processing name and parameter is executable. Instead of this arrangement, when each image processing plugin application <NUM> is installed, an image processing name and parameter corresponding to image processing executable by itself may be registered in linkage with the plugin application for the connection library <NUM>. This allows the connection library <NUM> to select an appropriate plugin based on information held by itself using an image processing name and a parameter without inquiring of each image processing plugin application.

The third embodiment of the present invention will be described below. In the above-described second embodiment, the connection library <NUM> selects a plugin by designating an image processing name and a parameter for the image processing plugin application <NUM>, and making an inquiry about whether image processing corresponding to them is executable.

However, time may be taken for processing if it is determined whether image processing is executable after designating an image processing name and a parameter for all the image processing plugin applications <NUM>. This is a case in which, for example, the number of image processing plugin applications <NUM> is large, or a large number of complicated determination logics of whether image processing is executable exist.

In the method of the above-described second embodiment, an inquiry about whether image processing is executable needs to be executed the same number of times as the number of image processing plugin applications <NUM>. With this method, an inquiry process about a plugin capability is performed even for an image processing plugin application without a function of performing designated image processing. For example, even for an image processing plugin application without a function of executing designated image processing, a function indicating a capability of the image processing plugin application is called, and confirmation processing for confirming whether image processing is executable with a designated parameter occurs. If a determination logic for executing this confirmation processing is complicated, a process that need not be executed primarily is to be executed. Furthermore, depending on an application, determination processing for determining whether designated image processing can be performed with a designated parameter may be executed even if the application does not have a function of performing the image processing. By executing these processes that need not be executed primarily, a search time is increased, or a processing load of the CPU <NUM> is increased.

To cope with this, in this embodiment, an image processing plugin application <NUM> is selected by operating two-stage filters, maintaining both a processing speed and flexibility. First, the filter of the first stage is applied to narrow down candidates for the image processing plugin applications <NUM> from only a designated image processing name. This is simply a process of finding out the image processing plugin applications <NUM> that hold an image processing name matching the designated image processing name. Then, the filter of the second stage is applied to select the appropriate image processing plugin application <NUM> by designating a parameter for the candidates narrowed down by the filter of the first stage and making an inquiry about whether processing is possible.

Filter processing of the first stage is the first selection processing for selecting plugin applications each capable of executing designated image processing by using an acquired image processing name. In addition, filter processing of the second stage is the second selection processing for selecting a plugin application capable of executing image processing according to a parameter out of plugin applications selected by the first selection processing. This needs to apply processing to only candidates narrowed down in advance, making it possible to suppress an increase in processing time as compared with a case in which the two-stage filters are not operated even if the logic for determining whether processing is executable is complicated.

The details of processing for calling the image processing plugin application <NUM> by a connection library <NUM> in this embodiment will be described with reference to a flowchart shown in <FIG>. Processing to be described below is implemented by, for example, loading programs stored in an HDD <NUM> in a RAM <NUM> and causing a CPU <NUM> to execute the programs. Note that the system arrangement and the processing procedure of this embodiment are the same as those described in the first embodiment above, a description thereof will be omitted, and only different portions will be described. More specifically, steps S901, S902, S908, and S909 are the same as steps S601, S602, S605, and S606.

In step S903, the connection library <NUM> designates an image processing name for all the installed image processing plugin applications <NUM> and makes an inquiry about whether a plugin corresponds to the image processing name. This is a process corresponding to the aforementioned filter of the first stage. In step S904, the connection library <NUM> determines whether the image processing plugin application <NUM> corresponding to the designated image processing name exists. If the image processing plugin application <NUM> exists, the process advances to step <NUM>. If the image processing plugin application <NUM> does not exist, the process advances to step S909. For example, in a case in which an image processing name "OCR" is designated in step S901, the process advances to step S905 if the image processing plugin application <NUM> holding the same image processing name as "OCR" exists. In step S905, the connection library <NUM> refers to a parameter designated in step S901. In step S906, the connection library <NUM> designates a parameter for the image processing plugin application <NUM> detected in step S904 and makes an inquiry about whether image processing corresponding to it is executable. In the above-described example, a parameter "language: English" is designated for the image processing plugin application <NUM> having the image processing name "OCR", and an inquiry about whether image processing is executable is made. At this time, as in the above-described second embodiment, a determination of whether image processing is executable is made depending on whether an OCR dictionary supporting English exists in a predetermined directory or lower inside the image processing plugin application <NUM>.

In addition, as the image processing plugin application <NUM> corresponding to the same image processing name, there is also a case in which both a plugin that performs processing inside an image forming apparatus <NUM> and a plugin that asks a server <NUM> to perform processing exist.

If image processing is performed inside the designated image forming apparatus <NUM>, a communication time with the server <NUM> is not needed as compared with a case in which the server <NUM> is asked to perform processing, making it possible to execute processing in a short time. On the other hand, since a memory is shared with another function in the image forming apparatus <NUM>, the memory may run short in some cases, influencing an operation of the other function. If the server <NUM> is asked to perform image processing, a memory of the image forming apparatus <NUM> is not used, preventing an influence given to the operation of the other function of the image forming apparatus <NUM>.

That is, if the memory does not run short in the image forming apparatus <NUM>, it is likely that a processing time can be shorter by executing processing by the image processing plugin application <NUM> which performs image processing inside the image forming apparatus <NUM> than by asking the server <NUM> to perform processing. On the other hand, if the memory may run short in the image forming apparatus <NUM>, it is preferable that processing is executed by the image processing plugin application <NUM> which asks the server <NUM> to perform image processing.

Therefore, the image processing plugin application may determine, in accordance with memory utilization when performing image processing that satisfies a designated parameter, whether the image processing plugin application can execute designated image processing.

For example, the image processing plugin application <NUM> that performs image processing inside the image forming apparatus <NUM> determines whether image processing is executable based on a parameter for an input resolution such as "input image resolution: <NUM> DPI". In order to execute image processing corresponding to "input image resolution: <NUM> DPI", the utilization of the RAM <NUM> at the time of execution is large and may influence the execution of another function. Therefore, the image processing plugin application <NUM> which performs processing inside the image forming apparatus <NUM> determines that the image processing is unexecutable.

In addition, the image processing plugin application <NUM> which asks the server <NUM> to perform processing determines that it is possible to execute the image processing because a memory space can be secured sufficiently in the server <NUM>.

On the other hand, if a parameter is "input image resolution: <NUM> DPI", the utilization of the RAM <NUM> at the time of execution is smaller than in the case of <NUM> DPI and is less likely to influence the execution of the other function. Accordingly, the image processing plugin application <NUM> which performs processing inside the image forming apparatus <NUM> determines that the image processing is executable.

In step S907, the connection library <NUM> determines, based on a designated parameter, whether the image processing plugin application <NUM> capable of executing processing exists. If the image processing plugin application <NUM> exists, the process advances to step S908. If the image processing plugin application <NUM> does not exist, the process advances to step S909.

According to a method shown in this embodiment, it becomes possible to maintain both the processing speed and flexibility by selecting the image processing plugin application <NUM> by operating the two-stage filters.

The present invention is not limited to the above-described embodiments, and various modifications can be made. For example, the image processing plugin application <NUM> that performs image processing inside the image forming apparatus <NUM> may dynamically determine, in accordance with not only a designated parameter but also a use situation of the RAM <NUM> in the image forming apparatus <NUM>, whether image processing is executable.

For example, the image processing plugin application <NUM> which performs processing inside the image forming apparatus <NUM> determines that the image processing is executable if the free space of the RAM <NUM> is equal to or larger than a predetermined space even in a case in which "input image resolution: <NUM> DPI" is input as a parameter. On the other hand, the image processing plugin application <NUM> which performs processing inside the image forming apparatus <NUM> determines that the image processing cannot be executed upon receiving "input image resolution: <NUM> DPI" as the parameter if the free space of the RAM <NUM> is smaller than the predetermined space.

The above-described processing will be described with reference to a flowchart in <FIG>. Processing by this flowchart is implemented by causing the CPU <NUM> to execute the image processing plugin application <NUM>. Processing to be described below is implemented by, for example, loading programs stored in the HDD <NUM> in the RAM <NUM> and causing the CPU <NUM> to execute the programs.

In step S1001, the image processing plugin application <NUM> acquires a threshold of a memory free space needed to execute image processing according to a designated parameter. For example, the image processing plugin application <NUM> manages information which associates an image processing parameter and a threshold concerning a memory space with each other, and acquires a threshold corresponding to the designated parameter with reference to the information. The association information is stored in, for example, a storage unit such as the HDD <NUM> of the image forming apparatus <NUM> when installing the image processing plugin application <NUM>.

Next, in step S1002, the image processing plugin application <NUM> acquires the free space of the RAM <NUM>. Step S1002 is space acquisition processing for acquiring the use situation of the memory of the image forming apparatus <NUM>. Subsequently, in step S1003, the image processing plugin application <NUM> determines whether the free space acquired in step S1002 is equal to or larger than the threshold acquired in step S1001.

If the free space acquired in step S1002 is equal to or larger than the threshold acquired in step S1001, the process advances to step S1004 in which the image processing plugin application <NUM> responds to the connection library <NUM> that the designated image processing is executable, thereby ending the processing. On the other hand, if the free space acquired in step S1002 is smaller than the threshold acquired in step S1001, the process advances to step S1005 in which the image processing plugin application <NUM> responds to the connection library <NUM> that the execution of the designated image processing is impossible, thereby ending the processing.

As described above, the image processing plugin application <NUM> determines, based on a memory use situation and a threshold concerning the memory use situation, whether a specific plugin application can execute image processing according to a parameter. It is thus possible, in accordance with the memory use situation of the image forming apparatus <NUM>, to dynamically respond with enabling/disabling of the execution of designated image processing. In addition, based on responded contents (determination result), the connection library <NUM> can select a plugin application capable of executing image processing according to a designated parameter.

In this modification, an example in which the image processing plugin application <NUM> determines whether designated image processing is executable has been described. However, the modification is not limited to this, and the connection library <NUM> may perform the determination. For example, the connection library <NUM> manages identification information of the image processing plugin application <NUM>, an image processing parameter, and a threshold concerning a memory space in association with each other. Then, based on the parameter and the threshold associated with the identification information of the image processing plugin application <NUM> of a determination target, the same processing as processing shown in <FIG> may be executed. In this case, processing shown in <FIG> is implemented by loading program codes stored in the HDD <NUM> in the RAM <NUM> and causing the CPU <NUM> to execute the program codes.

In step S1004, the connection library <NUM> determines that the image processing plugin application <NUM> of the determination target can execute designated processing. Furthermore, in step S1005, the connection library <NUM> determines that the image processing plugin application <NUM> of the determination target cannot execute designated processing.

It is also possible to dynamically determine, in accordance with the memory use situation of the image forming apparatus <NUM>, enabling/disabling of the execution of designated image processing in the above described manner.

Claim 1:
An image processing apparatus (<NUM>) capable of adding a function to be provided by installing a plugin application (<NUM>, <NUM>, <NUM>), the apparatus comprising:
accepting means (<NUM>) for accepting a request to execute predetermined image processing;
extracting means (<NUM>) for extracting, as character strings, an image processing name indicating a name of the predetermined image processing and a parameter related to the predetermined image processing, from the request accepted by the accepting means;
selecting means (<NUM>) for determining, from not less than one installed plugin application (<NUM>), whether a plugin application candidate corresponding to the image processing name extracted by the extracting means exists, if so, determining, from the at least one plugin application candidate, using the parameter related to the predetermined image processing, whether a plugin application capable of executing the predetermined image processing exists, and if so, selecting such a plugin application, and
instruction means (<NUM>) for instructing the plugin application selected by the selecting means to perform the predetermined image processing.