JP2007242052A - Process-to-process communication program and image information processor - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To independently develop an application and a control service to be provided in an image information processor while giving variability and diverseness to the application or a program for the control service. <P>SOLUTION: This process-to-process communication program which undertakes process-to-process communication by execution by an image information processor comprising applications for image information processing using hardware resources including a printing part or imaging part, an operating system and a program operated on the operating system and accessed by a plurality of applications to control the hardware resources makes the image information processor execute a function calling step of performing calling of a function of processing request or setting request related to image information processing to a program as a server process by an application as a client process. <P>COPYRIGHT: (C)2007,JPO&INPIT

Description

  The present invention relates to an inter-process communication program and an image information processing apparatus that perform inter-process communication between a server process and a client process that operate in an image information processing apparatus that performs a composite service such as a printer, copy, or facsimile.

  2. Description of the Related Art In recent years, an image forming apparatus (hereinafter, referred to as “multifunction machine”) in which functions of apparatuses such as a printer, a copy machine, a facsimile machine, and a scanner are housed in a single housing is generally known. This multifunction device is provided with a display unit, a printing unit, an imaging unit, and the like in one casing, and is provided with three types of software respectively corresponding to a printer, a copying machine, and a facsimile machine. It operates as a copy, scanner or facsimile machine.

  A conventional multi-function machine has a configuration in which software (including a general-purpose OS) corresponding to a printer, a copy, a scanner, and a facsimile machine is provided separately, and development of each software requires a lot of time. For this reason, the applicant has an application that has hardware resources used in image forming processing such as a display unit, a printing unit, and an imaging unit, and performs processing specific to each user service such as a printer, copy, or facsimile. When a user service is provided by interposing between these applications and hardware resources, hardware resource management, execution control, and image formation processing that are commonly required by at least two of the applications are provided. Invented an image forming apparatus having a platform comprising various control services. According to this image forming apparatus, it is possible to improve the efficiency of software development by including a platform that performs management, execution control, and image forming processing of hardware resources commonly required by at least two applications. In addition, the productivity of the entire apparatus can be improved.

  Such a multi-function peripheral has a control service that provides services that are commonly required by at least two of the applications. Therefore, it is possible to change functions, add functions, or add or change hardware resources in the future. It is desirable to be able to easily add or change for each application or control service in order to respond flexibly to the above. Further, when providing a composite service, it is necessary to smoothly exchange services and data between each application and each control service or between each control service.

  In other words, a multifunction device has a variety of functions such as printers, copiers, facsimiles, scanners, etc., but if some of the functions fail or specification changes occur, all applications or all control services If you have to modify these modules, the work effort will be excessive. Also, even if new functions are added to the MFP in the future, if it is necessary to change all control services and all application modules to add some functions, the program development effort will be excessive. End up. For this reason, it is necessary for each application and control service module operating on the multifunction peripheral to maintain the independence between the modules while realizing the transmission and reception of services and data with each other.

  In other words, if there is no independence for each application and each control service, it will be difficult to provide only the necessary applications and necessary control services, and the configuration of the MFP will be able to flexibly respond to function changes and additions. There is a problem that not only cannot variability be provided, but it is difficult to realize various functions.

  Further, if there is no independence for each application or each control service, there is a problem that it becomes difficult to design and construct each application or control service. That is, in a multi-function peripheral having a control service that provides a service that is commonly required by at least two applications, application program development is performed by a third party other than the manufacturer of the image forming apparatus by using the characteristic configuration. Although it may be left to the vendor, if each module is not independent, it will be difficult to develop an application if the third vendor is not familiar with the internal operation of the control service that directly interacts with hardware resources. Become. On the other hand, as a developer of an image forming apparatus, it is not preferable in terms of trade secret to disclose the internal operation of the control service to a third vendor.

  The present invention has been made in view of the above, and can provide variability and diversity to the application and control service program provided by the image information processing apparatus, and develop the application and the control service independently. An object of the present invention is to obtain an interprocess communication program and an image information processing apparatus that can be easily performed.

  In order to solve the above-described problems and achieve the object, the invention according to claim 1 is an application related to image information processing using hardware resources having a printing unit or an imaging unit, an operating system, and the operating system. An inter-process communication program that runs on an image information processing apparatus that operates on the image processing apparatus and that is executed by a plurality of applications and controls the hardware resources, and is responsible for inter-process communication. The application causes the image information processing apparatus to execute a function call step for calling a function of a processing request or a setting request for the image information processing for the program to be a server process.

  In the invention according to claim 2, the function calling step is a server process and calls a job control function for making a processing request or a setting request for an engine control service for controlling an engine as the hardware resource. It is characterized by that.

  According to a third aspect of the present invention, the function calling step is a server process and calls a memory control function that makes a processing request or a setting request to a memory control service that controls the memory and the hard disk as the hardware resources. It is characterized by performing.

  According to a fourth aspect of the present invention, the function calling step becomes the server process and makes a processing request or a setting request for a fax control service for controlling a fax communication using a fax control unit as the hardware resource. The facsimile communication control function is called.

  According to a fifth aspect of the present invention, there is provided an application for image information processing using hardware resources having a printing unit or an imaging unit, an operating system, and operating on the operating system, and accessed from a plurality of the applications. And a program for controlling the hardware resources, and the application includes function calling means for calling a function of a processing request or a setting request related to the image information processing for the program serving as a server process. It is characterized by.

  According to a sixth aspect of the present invention, the function calling means calls a job control function that makes a processing request or a setting request to an engine control service that controls the engine as the hardware resource as well as the server process. It is characterized by that.

  According to a seventh aspect of the present invention, the function calling means is a server process and calls a memory control function that makes a processing request or a setting request to a memory control service that controls the memory and the hard disk as the hardware resources. It is characterized by performing.

  In the invention according to claim 8, the function calling means makes a processing request or a setting request for a fax control service which controls the fax communication using the fax control unit as the hardware resource as well as the server process. The facsimile communication control function is called.

  According to the present invention, an application related to image information processing using hardware resources having a printing unit or an imaging unit, an operating system, and operating on the operating system, accessed from a plurality of the applications, and the hardware An inter-process communication program that is executed by an image information processing apparatus having a program for controlling resources and performs inter-process communication, and the image information processing for the program that becomes a server process by the application that becomes a client process By causing the image information processing apparatus to execute a function call step for calling a function of a processing request or a setting request related to a client, a client object program that operates on the image information processing apparatus while concealing a communication protocol is achieved. There is an effect that it is possible to develop a gram universally.

  In addition, according to the present invention, an application for image information processing using hardware resources having a printing unit or an imaging unit, an operating system, and operating on the operating system are accessed from a plurality of the applications and A program for performing control of hardware resources, and the application includes function calling means for calling a function of a processing request or a setting request for the image information processing for the program to be a server process. Thus, the configuration of the image information processing apparatus on which the client process operates can be made variable, and the image information processing apparatus can realize various functions.

  Exemplary embodiments of an interprocess communication program and an image information processing apparatus according to the present invention will be explained below in detail with reference to the accompanying drawings.

(Embodiment 1)
FIG. 1 is a block diagram showing a functional configuration of a communication program generating apparatus for image information processing apparatus (hereinafter referred to as “stub generator”) according to Embodiment 1 of the present invention. The stub generator according to the first embodiment automatically generates a header, a client stub, and a server skeleton from a message file.

  As shown in FIG. 1, an input unit 101 for inputting a message file 104, a syntax analysis unit 102 for checking the syntax of the contents described in the message file 104, a header 106 and a client stub from the description contents of the message file 104. 107 and a code generation unit 103 that generates a server skeleton 105 and stores it in a storage medium such as a hard disk.

  First, the message file 104 input to the stub generator of the first embodiment, the header 106 generated by the stub generator, the client stub 107, and the server skeleton 105 will be described. The message file 104 is a source file in which communication contents of inter-process communication are described in a source code such as C language.

  FIG. 3 is an explanatory diagram showing a description example of the message file 104. As shown in FIG. 3, the message file 104 includes another message file, an include declaration for declaring an include header of a C language description, a message description describing a message transmitted and received between the server process and the client process, The declaration of the function issued from the client process to the server process is described.

  A message is issued mainly when an event or notification is performed between a server process and a client process. As a message description of the message file 104, a message name, a message ID, a message direction, and a message content are described. It is supposed to be.

  Here, there are “IN”, “OUT”, and “SELF” in the message direction, “IN” means a message to be transmitted from the client process to the server process, and “OUT” is a message from the server process to the client process. Means a message to send to “SELF” means a message to be transmitted to its own process.

  The function is issued when a processing request or a setting request is issued from the client process to the server process. In the function declaration of the message file 104, only the function name, function type, and argument are described, and the processing contents of the function are not described.

  The client stub 107 is a source file describing the issuance of a function called from the client program to the server process. By compiling the client stub 107 into a library and linking with the client program, a function call from the client program is issued to the server process via the client stub 107.

  FIG. 4 is an explanatory diagram showing an example of the client stub 107 generated by the stub generator. As shown in FIG. 4, a function call is performed on the client stub 107 by calling a function handler registered in a server skeleton 105 described later.

  The server skeleton 105 is a source file in which a function handler and a message handler called from the client stub 107 are registered.

  FIG. 5 is an explanatory diagram showing an example of the server skeleton 105 generated by the stub generator. As shown in FIG. 5, in the server skeleton 105, function handlers corresponding to the functions described in the client stub 107 are registered. In the function handler, only the argument passing part is described, and the processing contents are described. The implementation description part to be created is generated in a blank state. In this implementation description section, the processing contents of the function issued from the client program via the client stub 107 can be freely described by the server program developer.

  The header 106 is a source file in which definitions and declarations common to the server skeleton 105 and the client stub 107 are described. FIG. 6 is an explanatory diagram showing an example of the header 106 generated by the stub generator. As shown in FIG. 6, the header 106 is generated in a state where an include declaration described in the message file 104, a message ID, a message declaration such as a message structure, a function declaration, a function handler declaration, and the like are described. It is like that.

  Next, generation processing of the server skeleton 105, the client stub 107, and the header 106 by the stub generator according to the first embodiment will be described. FIG. 2 is a flowchart of processing for generating the server skeleton 105, the client stub 107, and the header 106.

  The syntax analysis unit 102 of the stub generator performs a grammar check on the function declaration, message definition, include declaration, and C language description described in the message file 104 (step S201), and further, the function name defined in the message file 104 and The uniqueness of the message ID and message name in the message definition is determined (step S202).

  If there is a syntax error in the description of the function declaration, message definition, or include declaration, or if any of the function name, message ID, or message name is duplicated, a message to the user that it is a syntax error And the process ends (steps S203 and S204).

  After the syntax analysis, the code generation unit 103 generates a header 106, a server skeleton 105, and a client stub 107 from the description content of the message file 104. Specifically, the include declaration and C language description of the message file 104 are transferred as they are to the header 106, and the message structure described in the message definition of the message file 104 is copied to the header 106 (step S205).

  In addition, the code generation unit 103 automatically generates a function handler name from the function declaration of the message file 104 (for example, in the case of the function name abc, the function handler name is generated as abc_handler), and the generated function handler name is the server skeleton. Register within. In the function handler process, argument passing is described and issue of a return value area generation system call is described. Then, the field of the implementation description part describing the actual processing contents of the function handler is left blank, and after the implementation description part, the issuance of each system call for return value transmission and return value area release is described (step S206).

  For each function declaration described in the message file 104, the code generation unit 103 registers the function name and argument description in the client stub 107, and the function call message generation call and the function handler are included in the processing of the function. Each system call for calling and return value release is described (step S207). A function return value waiting system call that waits for a return value of the issued function is internally issued for the function handler call.

  When the client stub 107, the server skeleton 105, and the header 106 are generated by the tab generator in this way, the server object and the client object are then completed. The developer of the server program describes the processing contents to be performed by the function handler in the function handler implementation description section (blank) of the server skeleton 105 using an editor or the like, and compiles the server skeleton 105 together with the header 106 to Create a stub object.

  In addition, a function handler registered in the server skeleton 105 is declared, a message handler that transmits / receives a message described in the message file 104 to / from a client process, an error handler that performs error processing, a server initialization, a server dispatcher Create and compile a server source file that describes the issuance of system calls such as startup, and link with the server stub object to complete the server program.

  On the other hand, the client stub 107 is compiled with the header 106 to generate a client stub object. A client stub object is generated for each server process, and the plurality of generated client stub objects are used as a library.

  Also, function issuance, function handler declaration, error handler declaration for error handling, message handler for sending and receiving messages described in the message file 104 to and from the client process, client process initialization and client dispatcher A client program describing the issuance of system calls such as activation is created and compiled, and the client program is completed by linking with a stub library.

  FIG. 7 is an explanatory diagram showing a call and response sequence with the server program when a function call is made from the client program. Note that the server program and the client program are actually executable object files, but in FIG. 7, both are displayed in source code for convenience of explanation.

  When an Open function is called from the client program to the server program, for example, Open defined in the client stub object is called (step S701). Then, in the stub Open process, the Open function handler Open_handler is called to the server program (step S702).

  The server program receives the issuance of the function handler Open_handler from the client stub object, executes the process described in the implementation description part of the Open_handler registered in the server stub object (step S703), and outputs the execution result to the client stub. Is returned as a return value (step S704). The client program receives this return value from the client stub (step S705), and proceeds to the next processing.

  As described above, in the stub generator of the first embodiment, the client stub 107 and the server skeleton 105 can be easily generated by describing the function declaration in the message file 104. Moreover, since the implementation description part of the generated server skeleton 105 is blank, the program developer can easily change the function processing contents as necessary. For this reason, the multifunction peripheral can be provided with variability and various functions can be realized. In addition, even when a client program is developed by another company such as a third vendor, inter-process communication is possible simply by describing the function call provided in the client program, so the internal communication protocol is concealed. It becomes possible.

  Further, in the stub generator of the first embodiment, since inter-process communication is realized by function calls, high-speed inter-process communication is possible even when parallel execution of jobs is realized by threads. Further, since the threads can be synchronized by the return value from the function, it is not necessary to separately create a processing program for synchronization, and the labor for program development can be reduced.

(Embodiment 2)
The stub generator according to the first embodiment does not particularly limit the processes and threads that operate on the multifunction peripheral. However, the stub generator according to the second embodiment uses the control service that operates on the multifunction peripheral as a server process. Server skeleton, client stub, and header generation.

  The configuration of the stub generator of the second embodiment is the same as the configuration of the stub generator of the first embodiment shown in FIG. 1, and the client stub, server skeleton and header generation processing by the stub generator is also shown in FIG. Since it is the same as the processing procedure by the stub generator of form 1, description is abbreviate | omitted.

  Here, FIG. 8 is a block diagram illustrating a software configuration of the multifunction machine in which the server process and the client process generated by the stub generator according to the second embodiment operate. As shown in FIG. 8, the multi-function peripheral includes a monochrome line printer (B & W LP) 801, a color line printer (Color LP) 802, other hardware resources 803, and the like, and a software group 810 includes a platform 820 and an application 830. Consists of.

  The platform 820 includes a control service that interprets a processing request from an application and generates a hardware resource acquisition request, and a system resource manager that manages one or a plurality of hardware resources and arbitrates the acquisition request from the control service. (SRM) 823 and a general-purpose OS 821 such as UNIX (registered trademark).

  The control service is formed of a plurality of service modules, and includes an SCS (system control service) 822, an ECS (engine control service) 824, an MCS (memory control service) 825, an OCS (operation panel control service) 826, and an FCS. (Fax Control Service) 827 and NCS (Network Control Service) 828.

  The SCS 822 performs application management, operation unit control, system screen display, LED display, resource management, and interrupt application control. The ECS 824 includes a monochrome line printer (B & W LP) 801, a color line printer (Color LP) 802, and others. It controls engines such as hardware resources 803.

  The MCS 825 acquires and releases image memory, uses a hard disk device (HDD), compresses and decompresses image data, and the like. The OCS 826 is a module that controls an operation panel serving as information transmission means between the operator and the main body control.

  FCS 827 performs facsimile transmission / reception using PSTN / ISDN network from each application layer of the system controller, registration / quotation of various facsimile data managed by BKM (backup SRAM), facsimile reading, facsimile reception printing, and fusion transmission / reception. API is provided.

  The NCS 828 is a module group for providing a service that can be commonly used for applications that require network I / O. Data received from the network side according to each protocol is distributed to each application, and data is transmitted from the application. It mediates when transmitting to the network side.

  The application 830 includes a printer application 811 that is a printer application having a page description language (PDL), PCL, and postscript (PS), a copy application 812 that is a copy application, and a fax application 813 that is a facsimile application. A scanner application 814 that is a scanner application, a network file application 815 that is a network file application, and a process inspection application 816 that is a process inspection application.

  Each of these control services and each application transmits / receives various data to / from each other by inter-process communication using RPC (Remote Processor Call). The stub generator of the second embodiment generates a client stub and a server skeleton for realizing such inter-process communication with function calls.

  Next, a process for generating a server skeleton and a client stub when the ECS 824 is used as a server process and the function of the ECS 824 is used will be described.

  FIG. 9 is an explanatory diagram showing an example of a message file when the function of the ECS 824 is used as a server process. As shown in FIG. 9, in the message file, message definitions such as job handle, job execution availability notification, job end notification, etc. are defined, and as function declaration, job open request, job operation mode setting, job entry request, job start Declares functions such as request and job close request.

  As in the first embodiment, when this message file is input to the stub generator and executed, the client stub and server skeleton shown in FIG. 10 are generated, and the header shown in FIG. 11 is generated. As shown in FIG. 10, in the server skeleton, function handlers for job open request, job operation mode setting, job entry request, job start request, job close request are described with the implementation description part blank, and the client stub These function handler calls are described. Also, as shown in FIG. 11, messages such as a job handle, job execution availability notification, and job end notification are registered in the header.

  Then, the client program and the server program are generated from the client stub, the server skeleton, and the header generated in this manner, as in the first embodiment. For example, when the copy application 812 is used as a client program, a function call such as a job open request, job operation mode setting, job entry request, job start request, job close request or the like is described in the source file of the copy application 812. The copy application 812 is generated by compiling and linking with the client stub object.

  As a result, the copy application 812 sends an ECS 824 to the ECS 824 between the copy application 812 and the ECS 824 using the function call as a job open request, a job operation mode setting, a job entry request, a job start request, and a job close request regarding the job of the copy operation. Inter-process communication can be realized. In addition, inter-process communication can be performed from the ECS 824 to the copy application 812 using a message such as job execution enable / disable notification and job end notification.

  For inter-process communication between control services, for example, function calls such as job open request, job operation mode setting, job entry request, job start request, job close request, etc. are described in the source file of FCS827 and compiled in the same way When the FCS 827 is generated by linking with the client stub object, the job open request, job operation mode setting, job entry request, job start request, and job close request regarding the facsimile operation are function calls between the FCS 827 and the ECS 824. Interprocess communication can be realized.

  Next, a process for generating a server skeleton and a client stub when the FCS 827 is used as a server process and the function of the FCS 827 is used will be described. In this case as well, function declaration and message definition are performed in the message file in the same manner as when ECS 824 is used as a server process. When FCS 824 is used as a server process, function declarations such as transmission start and transmission mode change are made, and message definitions such as scan parameter notification are made.

  As in the first embodiment, when this message file is input to the stub generator and executed, a client stub, a server skeleton, and a header are generated. As in the case where the ECS 824 is used as a server process, the function handler for the transmission start and the transmission mode change in which the function declaration is made is described in the server skeleton, and the implementation description section is left blank, and these functions are displayed in the client stub. A handler call is described. In the header, a message such as a scan parameter notification in which the message is defined is registered.

  Then, the client program and the server program are generated from the client stub, the server skeleton, and the header generated in this manner, as in the first embodiment. For example, as the inter-process communication when the client program is ECS 824, function calls such as transmission start and transmission mode change are described in the ECS 824 source file, and similarly compiled and linked with the client stub object to perform ECS 824. Is generated, it is possible to realize inter-process communication between ECS 824 and FCS 827 using function calls for transmission start and transmission mode change for facsimile operation. Further, inter-process communication by a message such as scan parameter notification from the FCS 827 to the ECS 824 becomes possible.

  Next, processing for generating a server skeleton and a client stub when using the function of MCS 825 using MCS 825 as a server process will be described. In this case as well, function declaration and message definition are performed in the message file in the same manner as when ECS 824 is used as a server process.

  When MCS 825 is a server process, a memory image information request, a file generation request, a page generation request, a page information registration, a page open request, a page close request, a page information request, a page deletion request, a file information registration, In addition to function declarations such as file close requests, file open requests, file deletion requests, work area acquisition requests, work area deletion requests, and divided read requests, message definition such as job end notifications is performed.

  As in the first embodiment, when this message file is input to the stub generator and executed, a client stub, a server skeleton, and a header are generated. As in the case where the ECS 824 is a server process, the server skeleton includes a memory image information request, a file generation request, a page generation request, a page information registration, a page open request, a page close request, a page information request, for which a function declaration has been made. Function handler for page delete request, file information registration, file close request, file open request, file delete request, work area acquisition request, work area delete request, split read request is described with the implementation description part blank, and the client stub Describes these function handler calls. In the header, a message such as a job end notification for which a message has been defined is registered.

  Then, the client program and the server program are generated from the client stub, the server skeleton, and the header generated in this manner, as in the first embodiment. For example, as an inter-process communication when the client program is ECS 824, when a function call such as a memory image information request is described in the ECS 824 source file and ECS 824 is generated, a memory image information request is made to secure memory in the printer operation. It is possible to realize inter-process communication between ECS 824 and MCS 825 using a function call.

  Further, as inter-process communication when the client program is the scanner application 814, for example, a file generation request, page information registration, page open request, page close request, page information request, page deletion request to the source file of the scanner application 814, When function calls such as file information registration, file close request, file open request, file deletion request, work area acquisition request, work area deletion request, and divided read request are described and the scanner application 814 is generated, each request in the scanner operation It is possible to realize inter-process communication between the scanner application 814 and the MCS 825 using the function call.

  Further, as inter-process communication when the client program is ECS 824, for example, when ECS 824 is generated by describing function calls such as page generation request, page information registration, page close request, and page information request in the source file of ECS 824. The inter-process communication between the ECS 824 and the MCS 825 using each request in the scanner operation of a plurality of pages as a function call can be realized.

  As described above, the stub generator of the second embodiment can easily generate the client stub 107 such as an application and the server skeleton 105 such as a control service by describing the function declaration in the message file. In addition, since the implementation description part of the server skeleton generated by the stub generator is blank, the program developer can easily change the processing contents of the function as needed, and make the system variable. be able to. Furthermore, even when other companies such as third vendors develop application programs, inter-process communication is possible simply by describing the function calls provided in the application program, so the internal communication protocol is concealed. be able to.

  In the stub generator of the second embodiment, inter-process communication between control services or between a control service and an application can be realized by function calls, and parallel execution of jobs is started by activating a plurality of threads in the process. Even if it is realized, high-speed interprocess communication is possible.

  Furthermore, in the stub generator of the second embodiment, the threads can be synchronized by the return value from the function, so that it is not necessary to provide a separate synchronization process, and the program development effort can be reduced.

It is a block diagram which shows the functional structure of the stub generator of Embodiment 1 of this invention. 6 is a flowchart of a server skeleton, client stub, and header generation process in the stub generator of the first embodiment. 6 is an explanatory diagram illustrating a description example of a message file input to the stub generator according to the first embodiment. FIG. 6 is an explanatory diagram illustrating an example of a client stub generated by the stub generator according to the first embodiment. FIG. 6 is an explanatory diagram illustrating an example of a server skeleton generated by the stub generator according to the first embodiment. FIG. 6 is an explanatory diagram illustrating an example of a header generated by the stub generator according to the first embodiment. FIG. In Embodiment 1, it is explanatory drawing which shows the sequence of a call and a response with a server program when a function call is performed from a client program. FIG. 10 is a block diagram illustrating a software configuration of a multifunction machine in which a server process and a client process generated by the stub generator according to the second embodiment operate. In Embodiment 2, it is explanatory drawing which shows an example of the message file in the case of utilizing the function of ECS as a server process. FIG. 10 is an explanatory diagram illustrating an example of a client stub, a server skeleton, and a header generated by the stub generator according to the second embodiment. 12 is an explanatory diagram illustrating an example of a header generated by a stub generator according to a second embodiment. FIG.

Explanation of symbols

DESCRIPTION OF SYMBOLS 101 Input part 102 Syntax analysis part 103 Code generation part 104 Message file 105 Server skeleton 106 Header 107 Client stub 800 MFP 801 Monochrome line printer 802 Color line printer 803 Hardware resource 810 Software group 811 Printer application 812 Copy application 813 Fax application 814 Scanner application 815 Net file application 816 Process inspection application 820 Platform 821 General-purpose OS
822 SCS
823 SRM
824 ECS
825 MCS
826 OCS
827 FCS
828 NCS
830 Application 827 FCS

Claims (8)

An application for image information processing using hardware resources having a printing unit or an imaging unit, an operating system, and a program that operates on the operating system and is controlled by the plurality of applications to control the hardware resources An inter-process communication program for executing inter-process communication,
A function calling step for calling a function of a processing request or a setting request for the image information processing for the program to be a server process by the application to be a client process;
An inter-process communication program for causing the image information processing apparatus to execute.   The function call step calls a job control function that makes a processing request or a setting request to an engine control service that controls the engine as the hardware resource while being the server process. Interprocess communication program.   2. The function calling step calls a memory control function that makes a processing request or a setting request to a memory control service that controls the memory and hard disk as the hardware resource as well as the server process. Or the inter-process communication program of 2.   The function calling step calls a fax communication control function that makes a processing request or a setting request for a fax control service that controls the fax communication using the fax control unit as the hardware resource as well as the server process. The interprocess communication program according to any one of claims 1 to 3. An application for image information processing using hardware resources having a printing unit or an imaging unit;
An operating system,
A program that operates on the operating system and is accessed from a plurality of the applications to control the hardware resources,
The application is a function calling means for calling a function of a processing request or a setting request related to the image information processing for the program to be a server process,
An image information processing apparatus comprising:   6. The function calling means calls a job control function that makes a processing request or a setting request for an engine control service that controls the engine as the hardware resource as well as the server process. Image information processing apparatus.   6. The function calling means calls a memory control function that makes a processing request or a setting request to a memory control service that controls the memory and hard disk as the hardware resource as well as the server process. Or the image information processing apparatus of 6.   The function calling means calls a fax communication control function that makes a processing request or a setting request for a fax control service that controls the fax communication using the fax control unit as the hardware resource as well as the server process. The image information processing apparatus according to claim 5, wherein the image information processing apparatus is an image processing apparatus.

Images