Patent Description:
When developing software for executing information processing, a programming language (for example, a Java® language) having an importance on developing efficiency and a program language (for example, a C language or C++ language) having an importance on the processing speed are often used together. For example, the programming language having an importance on developing efficiency is used for development of a frequently updated program (for example, an application program). On the other hand, the programming language having an importance on the processing speed is used for development of a program (for example, an image processing program) for performing a complicated arithmetic operation. This can realize an arrangement in which a program for performing the complicated arithmetic operation can be operated at high speed while improving the developing efficiency of the frequently updated program. When a language having a function for automating memory management (a function of automatically performing management of a memory area used in a program) like the Java language is used as the program language having an importance on developing efficiency, installation can be performed with a light load and the developing efficiency can further be improved.

As a technique for using different programming languages together as described above, <CIT> discloses a technique for using a graphical programming language and text format programming language such as a C language together in a software developing environment of an embedded system. In <CIT>, an execution program developed in one programming language and an execution program developed in the other programming language are operated in the same execution environment, thereby allowing calling between the execution programs.

In a general calling mechanism which allows calling between different programming languages, however, the calling program and the called program share a logical memory space. If sharing of the logical memory space occurs, an error in the memory operation by the called program can influence the operation of the calling program.

The above error in the memory operation can occur in a program developed in a program language having no function for automating memory management. For example, an image processing program developed in the programming language having no function for automating memory management is called from an application program (application) and an error may occur in a memory operation by this image processing program. When the memory area used by the application is influenced by the error of the memory operation, an abnormality occurs in the operation of this application. For example, an abnormality such as erasure of customer data managed by the application and an accidental end of print processing controlled by the application occurs. A problem is posed in the operation of an apparatus itself in which the application is installed. <CIT> and <CIT> disclose an application desktop management in a portable device and performing a script layer control from a mobile device, respectively. <CIT> discloses an image forming apparatus including a plurality of Web page generating units.

The present invention has been made in consideration of the above problem. The present invention provides a technique for preventing an influence of an error of a memory operation by one program on the operation of another program, between programs developed in different programming languages.

The present invention in its first aspect provides an image forming apparatus as specified in claims <NUM> to <NUM>.

The present invention in its second aspect provides a method for controlling an image forming apparatus as specified in claim <NUM>.

According to the present invention, the influence of the error of the memory operation by one program on the operation of another program can be prevented between the programs developed in different programming languages.

The second embodiment thereof is a reference example outside the scope of the invention as claimed, which serves illustration purposes.

It should be noted that the following embodiments are not intended to limit the scope of the appended claims, and that not all the combinations of features described in the embodiments are necessarily essential to the solving means of the present invention.

Examples in which the present invention is applied to an image forming apparatus will be described in the following first to fourth embodiments. Note that the present invention is applicable to any apparatus if it is an information processing apparatus. The present invention is applicable not only to an image forming apparatus such as a printing apparatus, a copying machine, a multifunction peripheral, or a facsimile apparatus, but also to an information processing terminal such as a PC, a portable telephone, or a smartphone.

First, the first embodiment will be described below. <FIG> shows an arrangement example of an image forming system according to this embodiment. The image forming system includes image forming apparatuses <NUM> and <NUM>, 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 of (one or more) 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 to 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 realized by installing an additional plugin application in the image forming apparatus <NUM>.

<FIG> is a block diagram showing a hardware arrangement example of the image forming apparatus <NUM> according to this embodiment. 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> into the RAM <NUM> and executes the program loaded into 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 a 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 device to the image forming apparatus <NUM>. The extension I/F <NUM> is an interface having a USB (Universal Serial Bus) format, for example. If 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 allowing the user to perform an 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 written in a program language such as a C language and is an application originally provided (preinstalled) in 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> needs to be updated. The extension application <NUM> is an application written in 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>. Like the extension application <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>. 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 that executes processing by connecting to a library written in the Java language in the image forming apparatus <NUM>. The extension processing plugin <NUM> is an extension processing plugin that executes processing by connecting to an external server such as a cloud server. The extension processing plugin <NUM> is an extension processing plugin that executes processing by connecting to the native module <NUM> written in the C language.

The extension processing plugin <NUM> connects 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>. In 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, from the scan application, the execution request of the OCR processing for extracting a text image from the scanned image. 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 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.

Particularly, this embodiment will describe an arrangement for preventing an error (memory operation error) occurring in one use area from an influence on the other use area, by dividing the use areas of the process and memory between the extension processing plugin <NUM> and the native module <NUM>.

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>.

<FIG> is a block diagram showing a software arrangement example of the image forming apparatus <NUM> according to this embodiment. The software arrangement of the image forming apparatus <NUM> is implemented by using, 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 a Java® 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 which is 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> are written in 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 execution environment <NUM>. The uppermost layer includes plugin applications <NUM> and device control applications <NUM> and further includes the native client <NUM> and the connection library <NUM>. Each application of the uppermost layer is operated using an API (Application Programming Interface) 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 written in 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 a programming language such as the Java language is ease of writing a 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 writing 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 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 device (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 device via the network I/F <NUM>. In the scan transmission job, the data is transmitted via the network I/F <NUM> to, for example, the file server such as the server <NUM> or transmitted to an external device 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 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 that has 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 area separation can also 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 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 device 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. Upon 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, upon detecting a stop instruction to the plugin applications <NUM>, the CPU <NUM> instructs the stop of the plugin applications <NUM>. In addition, upon detecting an uninstallation instruction to the plugin applications <NUM>, the CPU <NUM> uninstalls the plugin applications by deleting the information of the plugin applications <NUM> from the HDD <NUM>. 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 the operating system <NUM> for control of necessary processing, thereby causing the job to be executed.

Next, the image processing plugin application <NUM> will be described in more detail. The image processing plugin application <NUM> is an application for providing 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>. In this embodiment, three applications corresponding to the extension processing plugins <NUM> to <NUM> in <FIG> are installed as the image processing plugin application <NUM>.

The image processing plugin application <NUM> can accept an image processing request (an image processing execution request) from the single function plugin application <NUM> (the extension 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> (the native application <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. 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> itself need not have an 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>. In this embodiment, the image processing plugin application <NUM> corresponding to the extension processing plugin <NUM> (<FIG>) uses the image processing function of the native module <NUM> (the native module <NUM>) via the native client <NUM>.

One of the reasons for causing the image processing plugin application <NUM> to use the native module <NUM> is a higher 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 such a case, a higher processing speed can be expected by using not a processing system that uses a programming language for performing processing via a virtual machine like Java, but by using a processing system that uses a compiler language for generating an object file that is directly executed by the CPU.

In this manner, the image forming apparatus <NUM> according to this embodiment includes the native client <NUM> and the native server <NUM> as a mechanism for calling a program executed in the C/C++ execution environment from the programs executed in the Java execution environment <NUM>. The native client <NUM> operates in the Java execution environment <NUM>, and the native server <NUM> operates in the C/C++ execution environment. Note that the Java execution environment <NUM> is an example of a first execution environment corresponding to a first programming language (Java language), and the C/C++ execution environment is an example of a second execution environment corresponding to a second programming language (C/C++ language).

In accordance with a request from the image processing plugin application <NUM> which is executed in the Java execution environment <NUM>, the native client <NUM> transmits a processing request for requesting the execution of the image processing using the native module <NUM> which is executed in the C/C++ execution environment. The native server <NUM> executes the image processing by receiving the processing request transmitted from the native client <NUM> and executing the native module <NUM> in accordance with the received processing request. This native server <NUM> is operated on the native control process <NUM> that has memory space independent of the memory space used by the Java execution environment <NUM>.

According to this embodiment, as described above, the logical memory space of the native control process <NUM> is independent of the logical memory space (the logical memory space used in the Java execution environment <NUM>) of 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 execution of the image processing in 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.

<FIG> is a flowchart showing the processing procedure by the image processing plugin application <NUM> according to this embodiment. Processing of the respective steps in <FIG> is implemented by the CPU <NUM> loading programs stored in the HDD <NUM> into the RAM <NUM> and executing the programs. This flowchart shows the processing procedure for using the image processing function of the native module <NUM> in a case where the image processing plugin application <NUM> accepts the image processing request from the request source. As described above, the request source (transmission source) of the image processing request is either the single function plugin application <NUM> and the device control applications <NUM> operating in the Java execution environment <NUM> or the device control libraries <NUM> operating in the C/C++ execution environment.

Note that at the time of activation of the image forming apparatus <NUM>, the CPU <NUM> activates the native client <NUM> in the Java execution environment <NUM> and activates the native control process <NUM> in the C/C++ execution environment. In addition, the CPU <NUM> activates the native server <NUM> on the native control process <NUM>. For this reason, when the image processing plugin application <NUM> accepts the image processing request, the native client <NUM> and the native server <NUM> have already been operated, so that a state of use from the image processing plugin application <NUM> is set.

Upon receiving the image processing request from the request source, the image processing plugin application <NUM> starts processing in accordance with the procedure shown in <FIG>. First, in step S401, the image processing plugin application <NUM> verifies image data serving as the target of image processing (information processing) included in the received image processing request. In this step, for example, the image format and image size of the image data are confirmed. Note that verification may be performed for other items as needed. Next, in step S402, the image processing plugin application <NUM> verifies the processing parameter concerning the image processing (information processing) included in the received image processing request. In this step, designation of, for example, an OCR language (Japanese, English, or the like) indicated by the processing parameter is confirmed.

Next, in step S403, in accordance with the contents of the image processing requested by the image processing request, the image processing plugin application <NUM> specifies the library name and function name of the native module <NUM> to be used. The library name represents the file name of an object file, for example, the file name (a file name having an extension ". dll") of a dynamic shared library used in Linux® or Windows. The function name represents the name of a function included in the object file specified by the library name. In this manner, the image processing plugin application <NUM> specifies a library and a function to be used by the native server <NUM>, based on the image data and processing parameter accepted from the request source of the image processing request.

After the library name and the function name are specified, in step S404 the image processing plugin application <NUM> prepares the image data input to the native module <NUM> to be used. In step S405, the processing parameter input to the native module <NUM> to be used is prepared.

After that, in step S406, the image processing plugin application <NUM> transmits, to the native client <NUM>, the image processing request that includes the image data and processing parameter respectively prepared in steps S404 and S405. The image processing request includes the library name and function name specified in step S403 as the designation of the library and function used in image processing. Accordingly, the image processing plugin application <NUM> requests the native client <NUM> to execute the image processing. Upon accepting this request, the native client <NUM> sends an image processing request to the native server <NUM> in accordance with a predetermined method. Note that the native server <NUM> executes image processing by the procedure (to be described later) shown in <FIG>, in accordance with the image processing request.

Next, in step S407, the image processing plugin application <NUM> determines whether or not the image processing execution result is received from the native client <NUM>. If the image processing plugin application <NUM> receives the execution result of the image processing based on the image processing request from the native server <NUM> via the native client <NUM>, it advances the process to step S408. Note that as will be described later, if the image processing by the native server <NUM> that is operating on the native control process <NUM> is complete, the image processing execution result is transmitted from the native server <NUM> to the native client <NUM>.

In step S408, the image processing plugin application <NUM> prepares data representing an image processing execution result to be returned to the image processing request source, transmits it to the request source, and ends processing. Note that the data to be returned changes in accordance with the contents of the requested image processing. For example, if image format conversion is requested, the converted image data is included in the data to be returned. In addition, if form recognition is requested, metadata such as a form type is included in the data to be returned.

<FIG> is a flowchart showing the processing procedure by the native server <NUM> according to this embodiment. Processing of the respective steps in <FIG> is implemented by the CPU <NUM> loading programs stored in the HDD <NUM> into the RAM <NUM> and executing the program.

If the native server <NUM> is activated, the native server <NUM> starts processing in accordance with the procedure shown in <FIG>. First, in step S501, the native server <NUM> performs preparation processing for waiting for a processing request from the native client <NUM>. In this embodiment, the native server <NUM> receives the processing request from the native client <NUM> by TCP/IP communication. For this reason, the native server <NUM> generates a server socket for TCP/IP communication with the native client <NUM> and waits for the communication by the generated socket. Note that waiting using an IPC (Interprocess Communication) message queue or the like in place of TCP/IP communication may be performed.

If the preparation processing in step S501 is complete, the native server <NUM> then waits for a processing request from the native client <NUM> in step S502. The native server <NUM> determines whether or not the processing request from the native client <NUM> is received. If the native server <NUM> detects the reception of the processing request, it advances the process from step S502 to step S503.

The native server <NUM> determines in step S503 whether the contents of the received processing request are an image processing request or a shutdown request. If the contents of the processing request are the shutdown request, the native server <NUM> advances the process from step S503 to step S510 and performs end processing for ending waiting of the processing request, thereby ending the processing. On the other hand, if the contents of the received processing request are an image processing request, the native server <NUM> advances the process from step S503 to step S504.

The native server <NUM> determines in step S504 whether or not a library (a library designated in the image processing request) corresponding to a library name included in the received image processing request exists in the native module <NUM>. If no designated library exists, the native server <NUM> advances the process to step S509, notifies the native client <NUM> of generation of an image processing error, and returns the process to step S502. After that, the native server <NUM> waits for a processing request again from the native client <NUM>. On the other hand, if the designated library exists, the native server <NUM> advances the process to step S505.

In step S505, the native server <NUM> loads the designated library of the libraries of the native module <NUM> from the HDD <NUM> into the RAM <NUM>. After that, the native server <NUM> determines in step S506 whether or not a function (a function designated in the image processing request) corresponding to a function name included in the received image processing request exists in the library loaded into the RAM <NUM>. If no designated function exists, the native server <NUM> advances the process to step S509, notifies the native client <NUM> of the generation of the image processing error, and then returns the process to step S502. After that, the native server <NUM> waits for a processing request again from the native client <NUM>. On the other hand, if the designated function exists, the native server <NUM> advances the process to step S507.

In step S507, the native server <NUM> designates the image data and processing parameter of the processing target in an argument of the designated function, and executes this designated function, thereby executing the image processing in accordance with the image processing request. In addition, if execution of this function is complete, the native server <NUM> transmits the image processing execution result to the request source (the native client <NUM>) in step S508, and returns the process to step S502. After that, the native server <NUM> waits for a processing request again from the native client <NUM>.

As has been described above, in this embodiment, the native server <NUM> operates in the C/C++ execution environment and executes the native module <NUM> (the second program) in accordance with the processing request from the native client <NUM>, thereby executing the image processing. The native server <NUM> operates on the native control process <NUM> that uses the memory space independent of the memory space used in the Java execution environment <NUM>.

According to this embodiment, an error in the memory server caused by the native server <NUM> on the native control process <NUM> can be prevented from influencing the operation of the application that is on the side for requesting the native server <NUM> to execute the image processing. For example, even if an error concerning the memory operation occurs when the native module <NUM> operates in accordance with a request from the device control applications <NUM>, its influence is limited to the native control process <NUM>. For this reason, even if such an error occurs, the device control applications <NUM> can prevent the influences on, for example, the transmission destination database held by the RAM <NUM> and print control by the device control libraries <NUM>. In this manner, the influences of the error in the memory operation in one program on the operation of the other program can be prevented between the programs developed in different programming languages.

Next, the second embodiment will now be described. Note that a description of portions common to the first embodiment will be omitted, and points different from the first embodiment will be described below.

In the first embodiment, TCP/IP communication is used in transmission of an image processing request from a native client <NUM> to a native server <NUM>, and this image processing request includes image data and processing parameters of a processing target. For this reason, as the size of the image data of the processing target increases, the communication time (time required for transfer of the image data) for the image processing request can be prolonged.

For example, it is assumed that the size of the image data of the processing target is <NUM> MB, the communication transfer throughput is <NUM> Mbps, and the size of the image data after image processing is equal to the size of the image data of the processing target. In this case, the transfer of the image data between the native client <NUM> and the native server <NUM> in an image forming apparatus <NUM> requires about <NUM> sec. If the image processing is complete in about <NUM> sec, time of about <NUM>% the time required for the image processing is required for the transfer of the image data, and a ratio of the overhead to the entire processing corresponding to the image processing request can be a ratio which cannot be neglected.

In this embodiment, the native client <NUM> does not transmit, to the native server <NUM>, data obtained by including the image data itself in the image processing request, and the native client <NUM> transmits data by including information (identification information) capable of specifying the image data in the image processing request. For example, a file path of a HDD <NUM>, like, "/var/docs/<NUM>/doc00001. tif", an ID of image data managed by a scan storage library <NUM>, or the like can be used as information capable of specifying the image data. In general, the size of such information is much smaller than the size of the image data. Therefore, by the above processing, the communication time between the native client <NUM> and the native server <NUM> can be shortened.

As has been described above, the native client <NUM> does not include the image data serving as the image processing target in the image processing request but includes in the image processing request and transmits the information for specifying the image data by the native server <NUM> together with the processing parameter. Accordingly, an image processing plugin application <NUM> can shorten the processing time for using the image processing function of a native module <NUM>. As a result, the image processing using the native module <NUM> can be performed at a higher speed.

Next, the third embodiment will be described. Note that a description of portions common to the first embodiment will be omitted, and points different from the first embodiment will be described below.

In the first embodiment, upon accepting the image processing request from a native client <NUM>, a native server <NUM> calls a function corresponding to the requested image processing and returns the function execution result as the image processing execution result. After that, the native server <NUM> is set in a state of accepting a processing request again. As described above, the native server <NUM> performs the requested image processing in an order of accepting image processing requests. In this case, if a plurality of image processing requests are generated, the native server <NUM> cannot start image processing corresponding to the next image processing request until the image processing corresponding to the previously received image processing request is complete.

For example, a user may use an operation unit <NUM> to operate a copy application <NUM> while the native server <NUM> is performing, in accordance with a request from a scan transmission application <NUM>, image processing for generating image data to be transferred to a server <NUM>. In this case, the native server <NUM> will not start the next image processing (the image processing requested from the copy application <NUM>) until the image processing requested from the scan transmission application <NUM> is complete. For this reason, the user who uses the copy application <NUM> must wait, thereby degrading usability for the user.

Accordingly, in this embodiment, in order to perform a plurality of image processing operations corresponding to the plurality of image processing requests in parallel, the native server <NUM> newly generates a thread for performing image processing every time an image processing request is accepted. This thread is a new thread that uses a memory space of a native control process <NUM>. Then, the native server <NUM> performs processing for waiting an image processing request and image processing corresponding to the accepted image processing request in parallel.

<FIG> is a flowchart showing a processing procedure by the native server <NUM> according to this embodiment. Processing of the respective steps in <FIG> is implemented by a CPU <NUM> loading programs stored in an HDD <NUM> into a RAM <NUM> and executing the program.

Steps S501 to S503 are the same as in the first embodiment. Note that in step S503, if the contents of processing request are determined as an image processing request, the native server <NUM> advances the process to step S601. In step S601, the native server <NUM> newly generates (activates) a thread for performing image processing corresponding to the received image processing request.

After generating the new thread in step S601, the native server <NUM> advances processing that uses the new thread to step S504, and at the same time, returns processing that uses the original thread to step S502. Accordingly, the native server <NUM> executes processing from step S504 using the new thread as in the first embodiment. On the other hand, in parallel with the processing using the new thread, the native server <NUM> waits (receives) for a new processing request from the native client <NUM> in step S502 using the original thread as in the first embodiment. Thus, in this embodiment, the new thread is a thread for performing processing from step S504, and the original thread is a thread for waiting a new processing request.

According to this embodiment, even if the native server <NUM> receives the plurality of image processing requests, the image processing operations corresponding to these requests can be executed in parallel, thereby shortening the processing time. Therefore, the usability can be improved for the user.

Next, the fourth embodiment will be described. The same parts as in the third embodiment will not be described, and points different from the third embodiment will be described.

In the third embodiment, every time the native server <NUM> receives an image processing request, a thread for performing image processing is newly generated, and a plurality of image processing requests can be simultaneously accepted. In contrast, in the fourth embodiment, every time the native server <NUM> accepts an image processing request, the native server <NUM> generates a new process different from a native control process <NUM> in place of generating a new thread in step S601. This process uses a memory space independent of the memory space used in the Java execution environment <NUM> and the memory space used in the native control process <NUM>. In addition, the native server <NUM> performs processing from step S504 on the generated process.

As described above, according to this embodiment, in the processing in step S601, the native server <NUM> does not activate a new thread but activate a new process, and performs image processing corresponding to the image processing request in this new process. On the other hand, the native server <NUM> waits for a new processing request from the native client <NUM> using the original process in step S502.

According to this embodiment, even between the simultaneously executed image processing operations, the logical memory spaces to be used can be separated from each other. Accordingly, an error in the memory operation in given image processing can be prevented from influencing another image processing. Therefore, the stability of the operation of an image forming apparatus <NUM> can be further improved.

Claim 1:
An image forming apparatus (<NUM>) comprising:
a plugin application (<NUM>, <NUM>, <NUM>),
a client (<NUM>, <NUM>) configured to transmit, in accordance with a request from the plugin application being a first program executed in a first execution environment (<NUM>) corresponding to a first programming language having a function of automatically performing management of a memory area used in the first program, a processing request for requesting execution of information processing using a second program (<NUM>, <NUM>) executed in a second execution environment corresponding to a second programming language having no function of automatically performing management of a memory area used in the second program, the client being operated in the first execution environment; and
a server (<NUM>, <NUM>) configured to receive the processing request transmitted from the client and execute the information processing by executing the second program in accordance with the received processing request, the server being operated in the second execution environment,
characterized in that
the server operates on a process (<NUM>) that uses a logical memory space independent of a logical memory space used in the first execution environment,
the processing request transmitted from the client includes data serving as a target of the information processing and a parameter concerning the information processing, and includes designation of a library and a function of the second program, and
if the execution of the information processing using the second program is complete, the server transmits the execution result to the client.